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.

Marc Canter seems pretty excited that Songbird is going to support XSPF. While Marc has written about it many times, I had no idea what it was. It’s the XML Shareable Playlist Format (pronounced “spiff”). It’s designed to be simple and open and built on XML. Typically, that’s coolness but while reading the spec, I had a strong sense of deja-vu. XSPF defines a list of songs for a playlist, much the same way that RSS defines a list of blog entries.

So that begs the question, why didn’t XSPF just use RSS instead of starting from scratch? RSS is simple, open, built on XML and is massively popular? Remember when Adam Bosworth that pointed out that RSS and Atom are “both support a base schema that provides a model for sets”. I’m all for a simple, open and extensible playlist format, but I’m not excited that XSPF has gone of an reinvented the concept of “list” in order to do it.

Hot on the heels of my post about the AJAX toolkit spectrum comes news that Yahoo! has released their own AJAX toolkit as well as a very cool web page design pattern catalog.

Some non-surprises:

• The Yahoo! toolkit has it’s own animation library, it’s own drag and drop library and it’s own XmlHttpRequest wrapper, just like other libraries like Dojo and prototype.
• The Yahoo! UI Controls depend on Yahoo’s Core Utilities. The libraries are modular, but not polymorphic with other these libraries.
• The code was released under an open source license (BSD).

All these different implementations of the same core set of capabilities at best means learning lots of ways of doing the same thing and at worst means incompatibility between components from different libraries.

BTW, last week I wrote that using a text-based high-level scripting language like Javascript in the browser “encourages business models where the in-browser code has little if any value.” This release from Yahoo! supports that point. While their mapping component is subject a strict Terms of Use, their UI components were released with a liberal open source licence. I doubt that’s a coincidence.

Last week, Dion wrote about the spectrum of AJAX tookits. He ended with a question, wondering which end of the spectrum will dominate? Will it be lightweight composable toolkits like prototype, script.aculo.us or Dojo? Or a more comprehensive toolkit like Atlas?

This came up in a chat I had w/ Jimmy Nilsson today. Well, not specifically about AJAX toolkits. Rather, we were talking about what he called technicalities vs. semantics:

I have noticed that there seems to be a focus first on the technicalities and then on the semantics. Take Indigo (or WCF) for example. There has been sooo much talk about its technical aspects, but very little talk about how to design for it. I’m pretty sure that when the technicalities have been sorted, it’s time for the semantic side. I’m not thinking about technical semantics, but rather business semantics.

On more than one occasion, I’ve had a head-beating-wall conversations with WCF folks who are completely obsessed with the secure, reliable and transactional delivery of messages, but have given exactly zero thought to the actual contents of said message. So I know where Jimmy is coming from.

With respect to AJAX toolkits, the question becomes just how easy will these lightweight toolkits compose? Because while Dion describes Google Maps as “a simple JavaScript include”, that’s just the technicalities, it doesn’t begin to deal with the semantics. For example, Dojo has Dictionary object, prototype has a Hash object. Dojo extends the Javascript Array, so does prototype. Both libraries wrap the XmlHttpRequest object. In each of these cases, it appears to me that the library authors have focused on the technicalities, but not thought about the semantics. These implementations are all semantically similar, but incompatible. So I don’t buy that these lightweight toolkits will compose well. What do I do if I’m using prototype but want the rich text editor in Dojo?

The network effect that Dion doesn’t consider is the component ecosystem phenomenon that Microsoft has a ton of experience with. Old school VB, COM/ActiveX and .NET have all had large ecosystems of components and controls evolve that extend the functionality of the baseline development platform. There’s no reason to believe that won’t happen with Atlas. I think it’s wrong to describe Atlas as a monolith or self-contained or enclosing. It’s an extensible baseline platform – i.e. the baseline functionality is set down once at the development platform and the ecosystem can extend it from there. Sure, overlapping extensions happen (how many rich text editor components are there for ASP.NET?) but at least they all have basic compatibility.

Update: Fixed link to Dojo Toolkit in the first paragraph.

Terra Nova is not the usual place I go to get news around programming language improvements. But they linked to a great presentation from POPL 2006 by Tim Sweeney of Epic Games. Tim’s talk is called The Next Mainstream Programming Language: A Game Developer’s Perspective and it talks at great length the major issues facing game developers today. As Nate Combs at Terra Nova remarked, most of these issues are not specific to the game industry, but will likely be seen there first.

Most interesting (to me) was the issue of concurrency. Tim uses Gears of War for all his examples. Of course, Gears of War is an Xbox 360 exclusive. Xbox 360, as many of you probably know, has three hyper-threaded CPUs for a total capactiy of six hardware threads. Herb Sutter talked about this in his DDJ article The Free Lunch Is Over. Tim points out – rightly so – that “C++ is ill-equipped for concurrency”. C#, Java and VB aren’t much better. Tim conculdes that we’ll need a combination of effects-free non-imperative code (which can safely be executed in parallel) and software transactional memory (to manage parallel modifications to system state).

Tim also touches on topics of performance, modularity and reliability. And he has an eye on the practical at all times. For example, he points out that even a four times performance overhead of software transactional memory is acceptable, if it allows the code to scale to many threads.

Anyway, it’s a great read so check it out. Also, MS Research has a software transactional memory project you can download if you’re so inclined.