Navigation:

« March 2005 | Main | July 2005 »

Gnomedex Wrapup

So now that Gnomedex 5 is over and I’ve had a few days to think things over, what were the significant developments? I think that there were 3…well, better make that 2-1/2 actually.

One: Microsoft Announces RSS Support

This was far and away the most important piece of news to come out of the conference. From my point-of-view, there were 5 pieces to this announcement:

  1. RSS reader as feature of IE7
  2. Enclosure support for multiple file/media types
  3. List extension namespace for RSS 2.0
  4. RSS aggregator platform support in Longhorn
  5. Implied RSS support in other Microsoft applications

RSS Reader as a Feature of IE7. This is essentially Microsoft playing catch-up with the other browsers such as Safari and Firefox. When Internet Explorer 7 encounters a web page with a feed on it, it will “light up” a button on the toolbar, which is currently the familiar white-on-orange “RSS” icon. (Caution: All user interface elements are subject to change before the final release.) If the user clicks on that button, then the feed will be “previewed” in the browser window (more on that in a second). Feeds are identified on a web page via the HTML <link> element. If there is more than one such <link> element on a page, then it’s the first one found that gets previewed and used for subscription. I don’t know if there’s any way for the user to override this. All current RSS flavors will be supported, including RSS 1.0, RSS 2.0 and Atom.

Currently in IE6 or Firefox, if you click on an RSS button on a web page, you’ll get an XML dump of the feed file. Clicking on the RSS button on the IE7 toolbar will give you a preview of the feed itself, without all of the nitty-gritty details being displayed. I use FeedDemon as my RSS reader, and from what I could see of the demo, this preview will look something like that product’s Channel Newspaper output, which is to say, a nicely formatted chronological list of titles and articles. I don’t know if feed authors or users will be able to change the details of this formatting. There will be some kind of search feature on the preview page so that the user can quickly find something they might be interested in.

Also on the preview page, there will be a button on the toolbar which will subscribe the user to the feed being displayed. Currently, that button is a big “+” symbol, but that will certainly change before release. The demos didn’t show much in the way of subscription list management and retention policy, but that will be there in some form or another.

All of this functionality is going to be released with the standalone version of IE7 so that users of current versions of Windows won’t have to upgrade to Longhorn in order to take advantage of this. Microsoft didn’t make any commitment as to a ship date for IE7.

While none of this so far is particularly earth-shaking news since other browsers and aggregators already do all of this, the simple fact that Microsoft is doing it all in the standalone version of IE7 means that many more people are going to be exposed to the benefits of RSS feeds. In spite of the rapid growth of Firefox on the Windows platform, IE is still far and away the dominant browser, and for many people, if it doesn’t exist within Internet Explorer, then it doesn’t exist.

Enclosure Support for Multiple File/Media Types. I don’t remember them saying much about this at the Gnomedex live demo, but it comes through loud and clear on the Channel 9 video which was shot the night before the announcement.

The RSS 2.0 <enclosure> element has historically—if 9 or 10 months counts as historical—been used mainly to deliver MP3 files to a “podcatcher” application, which is an RSS aggregator that knows MP3 files are considered to be podcasts, and handles them in such a way that they get automatically loaded onto the user’s media player, which is typically an Apple iPod or something similar. There’s no reason that this mechanism can’t be used for other kinds of enclosed files, and it’s exactly Microsoft’s intention to do just that.

The example that they showed in the demo was of an RSS feed item which contained 1 or more enclosures specifying iCal calendar data files. (It wasn’t clear to me whether this was a single feed item with multiple enclosures, or if it was multiple feed items each with a single enclosure. I guess it doesn’t really matter.) The iCal files were handed off to MS Outlook, where some special demo code the calendar events automatically into the Outlook calendar. They weren’t making an official announcement concerning any future version of Outlook, but the implication was clearly that this would be a standard feature at some point.

In the Channel 9 video, the Microsoft guys said that just about any file type can and would be supported in this fashion. Screensaver files could be automatically installed, documents, presentations and spreadsheets could be distributed, and so on. Again, they didn’t make any official annoucements, but they definitely indicated their intentions.

It wasn’t clear to me whether this was going to be a Longhorn feature, or if it would be available as part of the IE7 standalone release. I’m guessing that it’s a Longhorn feature.

List Extension Namespace for RSS 2.0. This is the feature that garnered the most attention and controversy because it’s the biggest and most obvious change. Microsoft has developed a specification for an XML namespace which, when used in conjunction with RSS 2.0, alters the semantics of RSS channels and their items or entries. An RSS channel or feed is implicitly a time-ordered list of what are essentially news articles. Microsoft’s Simple List Extensions basically remove the time-orderedness from the list, and allow the channel or feed to be simply a list of whatever you like.

If a reader or aggregator supports the extensions, then they need to support basic list operations such as sorting, insertion and deletion. If they don’t support the extensions, then they are simply ignored and the list is displayed as a normal RSS feed. The example that Microsoft demoed was of a wishlist on Amazon. They also talked about things like a wedding registry and other similar things.

The main points of controversy in the hall concerned whether or not this was a proper thing for Microsoft to be doing, that is, was this just a case of the standard MS strategy of Embrace, Extend, Extinguish, whether or not other developers could support these extentions, and whether or not they would support them. After much discussion, I think that the consensus was that it was okay for Microsoft to be doing this, and that developers could and would support the extensions. Microsoft has published the extensions under a Creative Commons license, so anyone can implement them, and they showed a video of Larry Lessig endorsing the concept.

My main question about all this is what are the aggregator developers going to do about this. Adding support for the extensions seems straightforward enough, but I’m thinking here at a higher level. Most aggregator applications are designed to be newsreaders. What should a newsreader do with a wedding registry list?

The other point of controversy occurred away from Gnomedex, on the blog postings of those who support Atom in place of RSS 2.0. Those people basically say something to the effect of “why extend RSS when you can just use Atom instead.” It’s not clear what Microsoft’s position on this is going to be. They’ve talked about supporting Atom, but that seems mainly in the content of IE7 being able to consume and display Atom feeds. The List Extensions are clearly intended to be used with RSS 2.0, and they haven’t made any mention of supporting an equivalent feature in Atom.

RSS Aggregator Platform Support in Longhorn. All aggregators and readers maintain some sort of list of subscribed channels or feeds, as well as some sort of database which contains all of the items from the feeds along with other metadata such as whether or not an items has been read, how long has it been in the database, and so on. Aggregators also have to implement some sort of retention policy so that the database doesn’t grow over time to overwhelm the available disk space. Microsoft intents to implement these basic structural functions within Longhorn itself, and to provide an API for developers to use to access these services.

In my opinion, this is exactly what a platform vendor should be doing with regard to a technology such as RSS: provide the basic structural support and allow developers to innovate on top of that. The big questions here are whether or not this structure will be truly open and fair: will all of the data and metadata be fully accessable to any application, or will there be private data and/or private API’s which only Microsoft applications have assess to?

Implied RSS Support in Other Microsoft Applications. There isn’t really much that be said about this right now. The Microsoft people didn’t make other official announcements concerning other Microsoft products. But the basic message comes through loud and clear: Microsoft as a whole thinks that RSS is a Big Deal, and they are intending to support it in every way imaginable, plus a few that are unimaginable. They specifically mentioned that MSN was doing some fairly obvious things with RSS, and the various demos that were shown are clear harbingers of things to come. I would expect to see various groups announcing their plans for RSS over the next 18 months to 2 years, the timeframe when Longhorn and all of it’s supporting cast will be delivered. In the meantime, I think it’s safe to assume that anything that Microsoft can do with RSS, they will do in the near future.

Bottom Line. I think that the short-term things that Microsoft is doing in terms of the additions to IE7 are fairly obvious enhancements—along with many others—that they have to do in order to catch up to the competition. Having basically gone silent for the past 4 years in the browser space, Microsoft has a lot of work ahead of them just to draw even again with the likes of Firefox, Safari and Opera. I think that the proposed list enhancements are a nice addition to the functionality of RSS, that seem to be well thought-out and should be a benefit to everyone. And finally, I think that the platform additions to Longhorn are absolutely the right thing for Microsoft to be doing.

On the other hand, Longhorn won’t be released to the public for another year and a half (or possibly longer), it will be another year or two before it reaches any significant share of the Windows base, and many more years after that before it becomes the dominant OS. All during that time, aggregator developers will have to maintain two versions of their code, one which takes advantage of the Longhorn RSS support if it’s present, and one which uses the developer’s own infrastructure if running on something other than Longhorn. A lot can happen in that amount of time, and it may very well be the case that by the time that Longhorn becomes sufficiently established, RSS may have moved in an entirely different direction. Time will tell.

Update: Here’s the real key to why I’m generally positive about this announcement. Microsoft has lost a lot of goodwill and credibility over the past decade or so, and they must realize that nobody trusts them. But having the trust and support of 3rd-party developers is criticial to Microsoft’s future survival. So here they are, asking for developer’s trust and support for this initiative. They must know that everybody will be watching them on this one. It’s a test case. So far, they are saying and doing the right things. But if they revert to their old behavior, it’s game-over for them as far as developers go. No one will ever trust them again.

Two: Adam Curry Announces Support for BitTorrent

Most podcasts are currently distributed via a direct file transfer from the author to the listener. When a new episode is posted by the author, there is typically a window of time of several hours in which a large number of listener’s aggregators attempt to download the new episode all more-or-less at the same time. This in turn puts a tremendous strain on the author’s server. One possible method for easing this strain would be for the podcast file to be encapsulated at a BitTorrent file, which would spread the download burden over many different systems.

This topic was one of many under discussion on a live-at-Gnomedex session of the Gillmor Gang, with Adam Curry being one of the panelists. When the subject came up, Adam said that he didn’t want to use BitTorrent to distribute his show, The Daily Source Code, because he didn’t want to be associated with a technology which itself is mainly associated with the piracy of copyrighted digital media files. The other panelists responded by urging him to take on the responsibility of banner-waver for BT exactly because his podcast is completely (well, mostly) non-infringing, and BitTorrent needs just such a high-profile, non-infringing application to give it credibility in the eyes of the law and the mainstream public. Adam said that he’d think about it.

Fortunately for everyone, Adam announced during his conference-ending keynote speech that he would indeed begin supporting BitTorrent. No further details were given, but hopefully it will start soon and hopefully it will include some or all of his other PodShow podcasts such as The Dawn and Drew Show and The Gillmor Gang.

The stakes were raised on this subject today when the Supreme Court of the U.S. ruled against the good guys in the Grokster case. Adam, I hope that this ruling doesn’t dissuade you because we need your support now more than ever. I’m sure that if you do run into any trouble, you’ll have the full support of the EFF, Larry Lessig and the entire community. Good luck, and remember that we’ll all behind you.

Three: Dave Winer Announces—But Sadly Doesn’t Ship—The OPML Editor

This is the 1/2 that I referred to at the top. Dave Winer has been working on The OPML Editor for several months now, and had earlier telegraphed that it would be ready to ship in time for Gnomedex. Unfortunately, there are apparently enough unsquashed bugs still remaining that Dave felt it wasn’t ready for a general release at this time, so we’re going to have to wait for another month or so. Oh well. Still, it’s better to have to wait then to release a buggy product onto unsuspecting users. We’ve all had our fill of that, I’m sure.

But, the good news is that Dave did demo The OPML Editor during his lead-off keynote address on Friday morning. It looks and works a lot like the editor from within Frontier, which is not surprising. But, instead of operating on Frontier object database data, it creates, opens, edits and emits OPML files, which is an XML schema for describing outlines. Additional features of the editor are that multiple users can share an outline file, making simultaneous updates which are immediately reflected to the other users, and it can be used to directly edit a weblog. I can hardly wait to get my hands on it!

One possible downside is that the user interface, at least in the initial release, looks a bit utilitarian. If you’ve ever seen Frontier, you’ll know what I mean. That’s probably okay if you’re a programmer or otherwise technically adept, but if you’re a more typical user like my mom or dad, then it might be a little intimidating. The good news is that Dave is releasing the code under an open source license—I think it was the GPL, but I’m not sure. That means that there’s on opportunity for someone to step up and take the code and turn it into a polished, commercial-quality outlining application. After all, if there was a decent market for ThinkTank and More 20 years ago, then surely there is an even bigger market for such a product today. There’s really nothing else like it out there.

Thanks Dave

Posted by Scott Trotter on June 27, 2005 at 03:04 PM | permalink

Intel Inside...Apple?

A number of people have recently asked me what I think about the Apple/Intel deal. This has been flogged to death on the net already, so I’ll just add a few brief observations.

So, to summerize:

Apple: Short-term loss of sales due to Osborne Effect, but recovering to current market share levels. In and of itself, the CPU switch probably won’t entice many current Windows users to switch to Mac.

Intel: Sales increase of 2-3% without having to battle AMD.

Microsoft: Windows licence revenue increase due to increased use of emulators on Macs.

Windows developers: Slightly larger potential market for their products, but probably not enough to get them really excited.

Macintosh developers: May eventually abandon native Mac applications in favor of relying on Windows emulators.

Now, all this is based on the participants stated intentions at this point in time. The deal also opens up some interesting possibilities should the parties—mainly Apple—choose to take advantage of them.

That’s all for now. Drop me a line and let me know what you think.

Posted by Scott Trotter on June 23, 2005 at 11:47 PM | permalink