I was able to catch an earlier flight home last night (which was itself delayed, but still got me home an hour and a half earlier than expected). Combined with the work that piled up while I was gone and I haven’t gotten around to the rest of my thoughts on Mashup Camp. Until now…

• This should have been in the day one update, but we had a great presentation Monday night on the History of Computer Marketing. Very interesting and very entertaining.
• It was good to see Marc Canter.
• There were fewer sessions on Tuesday because a significant amount of time was taken up on “speed geeking”. Supposedly similar to speed dating, but with mashup demos instead of dates. In actuality, it was more like demo anarchy with loud annoying buzzing.
• I spent a significant time with the folks from Bungee Labs (no relation to the makers of Halo). Like Ning, they are a web / mashup development site. However, where Ning appears to be going after the hobbyist, Bungee Labs is going after the enterprise. They had a cool demo of a SalesForce.com & Exchange mashup with maps.
• I was very impressed with WeatherBonk. In particular, the way they overlay the map with radar and fog information. They also make SkiBonk.
• I sat in on the Microformats Specification Work session, but didn’t get much out of it as it was a face-to-face meeting of core microformats folks rather than the “What are Microformats” session that I didn’t make the first day (conflict with Mashup Business Model session)
• There was a session on Firefox futures, but it was lame. You can get more from just reading the Firefox 2 product planning wiki page. Interestingly enough, if you look at their list of features for Firefox 2, only one is of any use to the web developer: In-line Spell Check. Everything else improves the chrome. Their priority one features are: new bookmark and history system, tabbed browsing UI improvements, extension manager enhancements, search engine UI improvements, and an update to the  browser appearance. As I wrote in Browser as VM, we’ve reached an inertia point where it’s hard for a browser vendor to add new proprietary capabilities that only work on their browser. Same goes for Microsoft – read the IE7 Technology Overview and while there is great work on things like security and the RSS platform, there are no new web developer feature, just bug fixes, better standards support and a native XmlHttpRequest object. I wonder what it’s going to take to get new capabilities added to arguably the most important virtual machine platform in the world.
• Podbop won the mashup contest. Chicago Crime came in second. Frankly, I was much more impressed with Chicago Crime.
• As the winner of the mashup contest, the guy that wrote Podbop got a Sun server. Second prize was a new intel-based Mac. And ten third place finishers got copies of Visual Studio Pro. Given that none of the mashup content entrants were built on Microsoft technology, I’d be interested to know how excited the third place finishers were about getting a copy of VS.
• I met a lot of great people at Mashup Camp (which is the primary reason I went) but above all I really got a lot out of hanging out with the MS folks who were there. We’re such a big company that it’s hard to keep abreast of what’s going on, so this kind of face-to-face time is invaluable.

That’s it, at least until Mashup Camp 2.

I don’t sleep well on the road so I’m exhausted. I’m going to post a couple of quick thoughts and then hit the sack.

• It was great to see Ward. When he got up to suggest a session topic he got a round of applause.
• I went to the morning session on Business Models for Mashups. Most interesting to me was the number of mashup developers not looking for funding. Either they don’t care much (it’s a hobby) or they think they can succeed w/o the extra cash. Otherwise, the session was lots of questions and not many answers.
• I spent lunch hanging out with Yoz from Ning. Ning is fascinating. Not sure I understand the business model (I think it’s ad-funded, but there aren’t many ads) but it’s definitely something I need to look into further.
• Session after lunch was on gadgets, widgets and modules. Interesting to see the major differences in each of the approaches. Scott Isaacs made some interesting points about the lack of an application model in the browser. But several folks seemed to imply that a web based application hitting a local web server was a good approach to offline apps. Why wouldn’t you just build a smart client app? The productivity of Windows Forms blows AJAX away (for now).
• I wanted to see Lawrence Lessig’s session on Creative Commons, but the room was too crowded. Similar problem to the Business Models for Mashups session, but even more so. I went and read email.
• Last session was about architecture patterns for AJAX applications, hosted by Scott Isaacs. It was more of a presentation than a discussion, but very interesting.
• Evening reception was sponsored by Yahoo! They had a cool ice sculpture and branded drinks – Yahootinis – with litecubes in them. My son Patrick is going to love these.
• I got to meet Sandy Kemsley, who is friends with my friend Chris Church who helped me get into Mashup Camp. I was instructed to buy Sandy a drink or three, but Yahoo! sprung for an open bar, so there was no buying. But we did have an interesting chat about workflow, business process and Office as a platform.

So I’ve already sold two of my new t-shirts. Not quite enough to retire on, but it’s a start! 😄

If nothing else, this has helped me realize just how popular Zazzle is. As I type this, my shirts are on page 20 of Zazzle’s most recent shirt list. That’s 304 new shirt designs since yesterday. That’s pretty impressive.

So after my two posts on XSPF and some public discussion in the comments, I took the conversation with Lucas offline in hopes of getting a better understanding about the thought process that went into the spec. Unfortunately, Lucas has reacted as if I called his baby ugly and we got nowhere. Needless to say, I still believe that XSPF is completely redundant because it is nearly semantically identical to RSS.

To demonstrate, here’s a list of every playlist element from the XSPF version 1 spec and how it maps to channel elements from RSS version 2.

• /playlist/title -> /rss/channel/title
• /playlist/creator -> /rss/channel/managingEditor
• /playlist/annotation -> /rss/channel/description
• /playlist/info -> /rss/channel/link
• /playlist/image -> /rss/channel/image
• /playlist/date -> /rss/channel/pubDate
• /playlist/license -> /rss/channel/copyright
• /playlist/location -> create custom element
• /playlist/identifier -> create custom element
• /playlist/attribution -> create custom element
• /playlist/link -> No need in RSS
• /playlist/meta -> No need in RSS
• /playlist/extension -> No need in RSS

That’s a pretty close match. There are a few things we need extensions for to represent in RSS, but nothing major. BTW, from what I can tell, the reason XSPF has link, meta and extension elements is for extensibility purposes. RSS supports an extremely flexible extensibility model already, so there’s no need for the XSPF specific extensibility elements.

Here’s the mapping of track elements in XSPF to item elements in RSS.

• /playlist/trackList/track/location -> /rss/channel/item/enclosure
• /playlist/trackList/track/identifier -> /rss/channel/item/guid
• /playlist/trackList/track/title -> /rss/channel/item/title
• /playlist/trackList/track/creator -> /rss/channel/item/author
• /playlist/trackList/track/annotation -> /rss/channel/item/description
• /playlist/trackList/track/info -> /rss/channel/item/link
• /playlist/trackList/track/image -> create custom element
• /playlist/trackList/track/album -> create custom element
• /playlist/trackList/track/trackNum -> create custom element
• /playlist/trackList/track/duration -> create custom element
• /playlist/trackList/track/link -> No need in RSS
• /playlist/trackList/track/meta -> No need in RSS
• /playlist/trackList/track/extension -> No need in RSS

Again, pretty close match. As you can see, the majority of the XSPF elements have a direct equivalent on the RSS side. Certainly, the most important elements (playlist title, list of tracks, track location) have a direct equivalent. For the remaining XSPF elements that have no RSS equivalent, you could easily extend RSS to support those elements. In fact, you can easily encode the sample playlists from the XSPF spec in RSS without any extensions whatsoever:

<rss version="2.0">
  <channel>
    <title>My Playlist</title>
    <link>http://devhawk.net/playlists/myplaylist</link>
    <description>Here's my playlist</description>
    <item>
        <enclosure length="..." type="audio/mpeg" url="http://example.com/song_1.mp3"/>
    </item>
    <item>
        <enclosure length="..." type="audio/mpeg" url="http://example.com/song_2.mp3"/>
    </item>
    <item>
        <enclosure length="..." type="audio/mpeg" url=http://example.com/song_3.mp3/>
    </item>
  </channel>
</rss>

So you may be wondering why I’m taken so much time on this topic. Frankly, I don’t really care one way or the other about XPSF. As I wrote in my last post, I’m just trying to understand this space better. The reason this specific example interests me is because it is so obviously a duplication of effort with little discernable upside. And furthermore it’s being touted by Marc Canter who I know is all about open standards. Why is the XSPF open standard better than the RSS open standard? Or Atom for that matter? Atom’s creators explicitly describe Atom’s syndication format as “an XML-based Web content and metadata syndication format”. How is XSPF different from that, other than narrowing the scope down to multimedia content and metadata? What’s the value of the narrow scope specification when the wider scope specification is so widely adopted?

As you might guess, my opinion is that the narrow scope specification has no value. I assume that’s why Lucas responded so negatively. But the root issue doesn’t go away. XSPF and RSS both describe lists of stuff. XSPF is specific to lists of media while RSS is typically used for lists of weblog entries but can be used for lists of anything – including media. What’s a podcast feed but an RSS encoded playlist?

The problem is that by introduced yet another syntax for basically the same semantics, XSPF can’t take advantage of the existing tools and platforms around RSS. And I’m not just talking about the Windows Feed API, I’m talking about every implementation of RSS on every website and in every news reader or podcatcher around. Why wouldn’t you want to ride that wave?

A while ago, I made a sign for my door that reads “Architecture Help 5¢” (in homage to Lucy’s psychiatry stand in Peanuts of course.) I get the occasional comment on it, so I decided to experiment and make a t-shirt out of it. These days, making your own t-shirt is cake with online services such as CafePress, T-Shirt Junky and Zazzle. I like Zazzle’s pricing structure the best – they have a flat fee and pay you a royalty on sales. CafePress has a baseline fee and you can then charge whatever you want on top of that. I didn’t want to be mucking around with pricing, so I went with Zazzle. Also, Zazzle has more choices and options for t-shirts than CafePress did.

My Zazzle gallery is named DevHawk Designs. So far, I have two products – the Architecture Help 5¢ shirt in black and in white, though Zazzle allows you to customize the shirt so you can get it on pink or navy blue if you really want it. I made it with Expression Graphic Designer, though it’s such a simple design I’m sure I didn’t really exercise its capabilities at all.

Other than me, I’m not sure who’s going to buy one of these. Believe me, I have no vision of being the next ThinkGeek. But let me know what you think, good or bad.