More on XSFP

Lucas Gonze left me a comment indicating they had in fact investigated using RSS for XSFP instead of starting from scratch. Good to know they considered the possibility. Unfortunately, it looks like they were using RSS 1.0 so it has all the extra RDF stuff which really hasn’t caught on. The document doesn’t really go into the reasons they chose to go a different way, though Lucas does say the following:

RSS didn’t make sense for a lot of reasons. We were paving cowpaths, and RSS for playlists was very much not a cowpath. Playlists are about sequence, while RSS has no concept of sequence except reverse chronological order. We needed abstractions to deal with the fact that music and movies frequently don’t have URLs, and RSS didn’t have them. If not starting from scratch was critical, HTML preceded RSS and would be the default to work from.

I’m not sure I get Lucas’ point about sequence. Both RSS and XSFP have sequence. Sure, RSS is typically describing web site content, thus it’s a reverse chronological order. But the RSS spec doesn’t mandate and specific meaning to the items in the feed. In fact, the items typically have a pubDate element making the order in the feed somewhat irrelevant. According to the spec, XSFP uses the order of the tracks in the file as the implicit playback order. Why that wouldn’t work with RSS is a mystery to me.

As for the “needed abstractions” missing from RSS, I’d be curious to know what those are and why they couldn’t be added via RSS extensions.

Lucas, please don’t take these comments as criticisms. I’m new in this space and I’m trying to get my head around stuff. Furthermore, if the success of RSS proves anything, it’s that number of users matters a lot more than the perceived technical merit of a given approach.

This entry was posted by DevHawk on February 15, 2006. It was tagged Music and Web 2.0.

Comments:

RSS is not about lists so much as it's about reverse-chronological journals. There are assumptions about the weblog form buried deep in the format, for example the idea that all entries would have some sensible reason to have a pubDate. We could indeed do playlists as an RSS extension, and at the time we started on XSPF some people were experimenting with that. Those experiments didn't work out for three reasons. One, many RSS features just weren't applicable to playlists and would create needless verbosity. Two, many playlist features weren't already in RSS and would have to be invented no matter what we did. Three, our target user base was developers of MP3 players, who would be actively turned off by having to deal with RSS. XSPF is much much much simpler than RSS. On the whole, an RSS-based approach would have been buggier, harder, and hard to sell. Now my question for you: why are you looking at multimedia through RSS-colored glasses? Why should web logs be the model for playlists?
This comment was posted by Lucas Gonze on February 15, 2006 at 6:26 PM.
I believe your understanding of RSS to be flawed. If you read the 2.0 spec, you'll notice that there are no assumptions baked into the spec. Sure, it's primarily used for weblogs, but RSS doesn't mandate weblogs. For example, your point about pubDate is incorrect. PubDate, like all other defined item elements, is optional. From the link you left in your last post, it's pretty clear you were looking at the 1.0 version of the RSS spec which was significantly more verbose. Have you looked at the 2.0 spec? I'm not looking at multimedia through RSS-colored glasses. I'm seeing yet another list format that is semantically similar but syntactically different from RSS. That means that instead of using well known (and well tested) RSS libraries to process playlist feeds, I have to write everything from scratch. That creates more bugs, not less. Given the popularity of podcasting - which of course uses RSS as the feed format - RSS for multimedia seems to be working well already. From my reading of the spec, an XPSF feed is basically an RSS feed without some of the elements that are optional in RSS anyway.
This comment was posted by DevHawk on February 16, 2006 at 10:39 AM.
That's XSPF, not XPSF. It is silly to say that there are no assumptions baked into the spec.
This comment was posted by Lucas Gonze on February 16, 2006 at 11:54 AM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.