I accidentally caught Al Sharpton on Saturday Night Live last night and it was a horrible experience. Not only was the show as unfunny as getting needles shoved in your eyeballs  (why the fuck do good shows like Futurama and Family Guy get cancelled but this turd continues to stink up the airwaves?) but our pal Al keep fumbling his lines like he'd forgotten them and kept having to surreptituously read them from the teleprompter. What a joke.

Definitely a horrible way to end a Saturday night.

 

Shelley Powers writes

For instance, The W3C TAG team -- that's the team that's defining the architecture of the web, not a new wrestling group -- has been talking about defining a new URI scheme just for RSS, as brought up today by Tim Bray. With a new scheme, instead of accessing a feed with:

http://weblog.burningbird.net/index.rdf

You would access the feed as:

feed://www.tbray.org/ongoing/ongoing.rss

I've been trying to avoid blogging about this discussion since I'll be leaving for Philly to attend the XML 2003 conference in a few hours and won't be able to participate in any debate. However since it seems some folks have started blogging about this topic and there  some misconceptions in their posts I've thrown my hat in the ring.

The first thing I want to point is that although Shelley is correct that some discussion about this has happened on the W3C Technical Architecture Group's mailing list they are not proposing a new URI scheme. Tim Bray was simply reporting on current practices in the RSS world that I mentioned in passing on the atom-syntax list.

THE PROBLEM
The problem statement is "How does a user go to a website such as http://news.yahoo.com or http://www.slashdot.org, who'd like to subscribe to information from these sites in a client-side news aggregator do so in a quick and painless manner?". The current process is to click on an icon (most likely an orange button with the white letters 'XML' on it) that represents an RSS feed, copy the URL from the browser address bar, fire up your RSS client and click on the subscribe dialog (if it has one).

This is lot of steps and many attempts have been made to collapse this into one step (click link and the right dialog pops up). 

PREVIOUS SOLUTIONS TO THE PROBLEM
The oldest one I am aware of was pioneered by Dave Winer and involved client side aggregators listening on a port on the local machine and a hyperlink on the website linking to a URL of the form http://127.0.0.1:5335/system/pages/subscriptions. This technique is used by every Radio Userland weblog and is even used by dasBlog which is my blogging tool of choice as is evidenced by clicking on the icon with a picture of a coffee mug and the letters "XML" on it at bottom of my weblog.

There are two problems with this approach. The first is the security issue brought on by the fact that you have a news aggregator listening on a socket on your local machine which could lead to hack attempts if a security exploit is found on in your news aggregator of choice, however this can be mitigated by firewalls and so far thus hasn't been a problem. The second is that if one has multiple aggregators installed there is contention for which one should listen on that port. For this reason different aggregators listen on different local ports; Radio listens on port 5335, AmphetaDesk listens on port 8888, Awasu listens on port 2604, nntp//rss listens on port 7810 and so on.

An alternative solution was chosen by various other aggregator authors in which hyperlinks pointed to the URLs of RSS feeds with the crucial distinction that the http:// part of the URL was substituted with a custom URI scheme. Since most modern browser have a mechanism for handing off unknown URI schemes to other client applications this also allows "one-click feed subscription".  Here also there is variance amongst news aggregators;  Vox Lite, RSS Bandit & SharpReader support the feed:// URI scheme, WinRSS supports the rss:// URI scheme while NewsMonster supports the news-monster:// scheme.

With all this varying approaches, it means that any website that wants to provide a link that allows one click subscription to an RSS feed needs to support almost a dozen different techniques and thus create a dozen different hyperlinks on their site. This isn't an exaggeration, this is exactly what Feedster when one wants to subscribe to the results of a search. If memory serves correcly, Feedster uses the QuickSub javascript module to present these dozen links in a drop down list.

THE FURORE
The recent debate on both the atom-syntax and the www-tag mailing lists focuses on the feed:// URI proposal and it's lack of adherence to guidelines set in the current draft of Architecture of the World Wide Web document being produced by the W3C Technical Architecure Group. This document is an attempt to document the architecture of the World Wide Web ex post facto.

Specifically the debate hinges on the guideline that states

Authors of specifications SHOULD NOT introduce a new URI scheme when an existing scheme provides the desired properties of identifiers and their relation to resources.
...
If the motivation behind registering a new scheme is to allow an agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense by registering a new Internet Media Type instead. Deployed software is more likely to handle the introduction of a new media type than the introduction of a new URI scheme.

The use of unregistered URI schemes is discouraged for a number of reasons:

• There is no generally accepted way to locate the scheme specification.
• Someone else may be using the scheme for other purposes.
• One should not expect that general-purpose software will do anything useful with URIs of this scheme; the network effect is lost.

The above excerpt assumes that web browsers on the World Wide Web are more likely to know how to deal with unknown Internet Media Types than unknown URI schemes which is in fact the case. For example, Internet Explorer  will fallback to using the file extension of the file if it doesn't know how to deal with the provided MIME type (see  MIME Type Detection in Internet Explorer for more details). However there are several problems with using MIME types for one click feed subscription that do not exist in the previously highlighted approaches.

Greg Reinacker detailed them in hist post RSS and MIME types a few months ago.

Problem 1: [severity: deal-breaker] In order to serve up a file with a specific MIME type, you need to make some changes in your web server configuration. There are a LOT of people out there (shared hosting, anyone?) who don't have this capability. We have to cater to the masses, people - we're trying to drive adoption of this technology.

Problem 1a: [severity: annoyance] There are even more people who wouldn't know a MIME type from a hole in the head. If Joe user figures out that he can build a XML file with notepad that contains his RSS data (and it's being done more often than you think), and upload it to his web site, you'd think that'd be enough. Sorry, Joe, you need to change the MIME type too. The what?

Problem 2: [severity: deal-breaker] If you register a handler for a MIME type, the handler gets the contents of the file, rather than the URL. This is great if you're a media player or whatever. However, with RSS, the client tool needs the URL of the RSS file, not the actual contents of the RSS file. Well, it needs the contents too, but it needs the URL so it can poll the file for changes later. This means that the file that's actually registered with a new MIME type would have to be some kind of intermediate file, a "discovery" file if you will. So now, not only would Joe user have to learn about MIME types, but he'd have to create another discovery file as well.

Many people in the MIME type camp have pointed out that problem two can be circumvented by having the feed file contain it's location. Although this seems a tad redudundant and may be prone to breakage if the website is reorganized it probably should work for the most part. However there is at least one other problem with using MIME types which people have glossed over. 

Problem 3:  If clicking on a link to an RSS feed in your browser always invokes your aggregator's feed subscription dialog then this means you can't view an RSS feed in your browser if you have a client aggregator installed and may not be able to view even if you don't because your browser of choice may not know how to handle the MIME type if it isn't something like text/xml.

At least one person, Tim Bray, doesn't see this as a big deal and in fact stated, "why not? Every time I click on a link to a PDF doc I get a PDF reader. Every time I click on a .mov file I get Quicktime. Seems like a sensible default behavior".

THE BOTTOM LINE
Using MIME types to solve the one click subscription problem is more diffficult for weblog tools to implement than the other two approaches favored by news aggregators and requires changing web server configurations as well while the other approaches do not. Although the architecure astronauts will rail against the URI scheme based approach it is unlikely that anyone who looks dispassionately at all three approaches will choose to use MIME types to solve this problem. 

Of course, since one of the main forces behind the ATOM movement has stated that MIME types will be the mechanism used for performing one click subscription to ATOM feeds this just seems like one more reason for me to be skeptical about the benefits of adopting the ATOM syndication format.

 

The BBC has a contest to vote for the Ten most embarrassing political moments. Funny enough they don't have the my favorite, the projectile vomitting incident involving George Bush senior and Kiichi Miyazawa of Japan.

When Mr Bush's father attended a state visit in Japan in January 1992, he responded to the arrival of Japanese beef steak (French-style) with a projectile vomit into the lap of Prime Minister Kiichi Miyazawa.

Suffering from flu at the time, George Bush Senior then slumped under the table before getting up a few minutes later and announcing he felt great. 

Too bad there isn't an option for a write-in vote.

 

I've gotten a complaint that in some cases it seems you need a Microsoft Passport account to download the latest version of RSS Bandit. For this reason I've setup an alternate download location, for anyone who's having this problem and doesn't have a Microsoft Passport account.

Enjoy.

 

Download it here. New features and bug fixes described below.

Differences between v1.2.0.43 and v1.1.0.61 below.

• FEATURE: One can now search for feeds by keyword as well as by URL. This means one can search the for 'CNN', 'RSS Bandit' or 'XML' and get back up to a hundred feeds back from the Syndic8 database that contain that requested text in the description. Very useful for browsing for new feeds to subscribe to.
  
• FEATURE: Added an [Apply] button to the Options dialog so one can test features such as the various XSLT themes for displaying feeds (the DOS theme is still my favorite) without having to close the dialog.
  
• FEATURE: Now provides visual indication when downloading the comments for a particular feed that supports wfw:commentRss.
  
• FEATURE: Added a tab in the options dialog for configuring the web search engines available from the Search toolbar (still have MSN Search, Feedster and Google by default)
  
• FEATURE: Option added to network settings dialog to take over proxy settings from Internet Explorer.
  
• FEATURE: Support for the feed:// URI scheme proposed by Greg Reinacker
  
• FEATURE: New user interface with an Office 2003 look & feel courtesy of Tim Dawson's SandBar controls
  
• FEATURE: Ability to subscribed feeds for items that contain a particular keyword (via View->Rss Search).For example,  searching for all posts with "RSS Bandit" in their content.
  
• FEATURE: now you can restrict the security settings of the embedded web browser (via Tools->Options->Web Browser). By default now only allows download of images, but no Javascript, ActiveX or Java applets.
  
• FIXED: Problem that occured infrequently where at certain times moving, renaming or deleting category nodes led to corruption of feedlist.xml file.
  
• FIXED: Clicking on a category node in the tree view no locks up the application thus making it unusable.
  
• FIXED: Certain websites which use "deflate" compression without headers caused exceptions on attempts to decompress the feeds such as MSDN or dasBlog feeds.
  
• FIXED: Maximum age to keep feed items sometimes is inconsistent between the value set in the options dialog and the value used for particular feeds.
  
• FIXED: Too many spurious XML-related errors showing up in 'Feed Errors' special folder.
  
  

 

Check out the screenshots of the two newest features added to RSS Bandit; filtered search and locating RSS feeds by keyword.
 

My latest column is up on MSDN, Extreme XML: EXSLT Meets XPath.

 

Robert Scoble wrote

I see over on Evan Williams site that it looks like Google (er, Blogger, which is owned by Google) is going to support Atom. So far Microsoft has been supporting RSS 2.0 (we've spit out RSS 2.0 on MSDN, on the PDC app, on MyWallop, and in a few other places). Atom is a syndication format that's similar, but slightly different from RSS. I wonder how the market will shake out now.

Evan: can you explain, in layman's terms, why you support Atom and not RSS?

This question is misleading. There are two parts to ATOM that are being discussed by Google, the ATOM API and the ATOM syndication format. The ATOM API is competitive with technologies like the Blogger API, MetaWeblog API and the LiveJournal API while the ATOM syndication format competes with technologies like RSS 1.0 and RSS 2.0.

There has been enough written about the history of feed syndication formats named "RSS" so I'll skip that discussion and move directly to discussing the history of weblog posting APIs.

The Blogger API was originally developed by Blogger (now owned by Google) as a way of allowing client applications to talk to blogger weblogs (using client applications such as w.bloggar). This API was later adopted by other blogging tools such as Radio Userland. However Dave Winer decided he didn't like some of the perceived deficiencies in the Blogger API and forked it thus creating the MetaWeblog API. Later on the Blogger folks came out with version 2.0 of the Blogger API which led to online war of words with Dave Winer because he felt they should use his forked version instead even though his version removed functionality that was crucial to Blogger. Eventually Blogger backed off from implementing v2.0 of thier API and has been waiting for an alternative which presented itself in the ATOM API. Most of this history is available from  Evan Williams's blog post entitled the Tragedy of the API.

<update source="Dave Winer" >

1. ManilaRPC came first, way before all the others you mention. It was an XML-RPC then SOAP-based API for driving Manila, and is still in use today, and is much deeper than any of the other APIs.
2. The MetaWeblog API addressed a very well-known deficiency in the Blogger API, no support for titles. You neglected to mention that it was broadly supported by tools and blogging systems, by everyone except Blogger.

</update>

The ATOM effort is aimed at replacing both the popular syndication formats and the popular weblog publishing APIs. Both of which have been burdened with histores full of turbulent turf battles and personal recriminations.  

Based on my experiences working with syndication software as a hobbyist developer for the past year is that the ATOM syndication format does not offer much (if anything) over RSS 2.0 but that the ATOM API looks to be a significant step forward compared to previous attempts at weblog editting/management APIs especially with regard to extensibility, support for modern practices around service oriented architecture, and security. The problem is that if one implements the ATOM API it makes sense that since this API uses the feed syndication format as the payload of the messages sent between the client and the server then one should also implement the ATOM syndication format. This is probably why Blogger/Google will support both the ATOM API and the ATOM syndication format.

I personally tend to agree with Don Park's proposal

IMHO, the most practical path out of this mess is for the Atom initiative to hi-jack RSS 2.0 and build on it without breaking backward compatibility.  A new spec will obviously have to be written to avoid copyright problems with Dave's version of the RSS 2.0 spec, but people were complaining about the old spec anyway.

As to the Atom API, I won't bitch about it any more if RSS 2.0 is adopted as the core Atom feed format because the feed format is far more important than the API.  This should satisfy Evan Williams since his real beef is with the API.  Yes, there are some issues people have with RSS 2.0 but they can be ignored or worked-around with extensions until later, hopefully much later.

This compromise will give the best of all world's to users. There is no discontinuity in syndication formats yet blog editting APIs are improved and brought in line with 21st century practices. I've mentioned this on the atom-syntax mailing list in the past but the  idea seemed to receive a cold reception.

Regardless of what ends up happening, the ATOM API is best poised to be the future of weblog editting APIs. The ATOM syndication format on the other hand...

 

I've begun to dread every time I see a blog entry in my aggregator with "XAML" in the title. It usually means I am either going to read a lot of inane fanboy gushing about the latest and greatest from Microsoft or some FUD from some contingent that either misunderstands the technology or has an axe to grind with Microsoft. So much so, I've been contemplating adding a "hide entry if contains keyword" feature to RSS Bandit so I never have to read another post about XAML. Anyway, back to the point of my post.

Diego Doval has an entry entitled XAML and... Swing which contained a number of opinions that completely perplexed me. I'll go over each one in turn.

XAML will be Windows-only, so in that sense the comparison is stretched. But this is a matter of practice, in theory an XML-based language could be made portable (when there's a will there's a way). XAML was compared a lot to Mozilla's XUL, and rightly so, but I think there are some parallels between it and Swing as well.

In theory, every language targetted at a computer is portable to other platforms. However if I wrap XML tags around  C++ code that uses Win32 API calls, how portable is that in practice? As for parallels between XAML and Swing, I thought this was extremely obvious. XAML is the XML-ized way to write what one could consider to be the next generation WinForms (managed APIs for interacting with Windows GUI components)  applications. In fact, someone has already implemented XAML for WinForms, called Xamlon. Considering that Swing (Java APIs for interacting with operating system  GUI components) is analogous to Winforms it isn't a leap to see a parallel to XAML and Swing.

One big difference that XAML will have, for sure, is that it will have a nice UI designer, something that Swing still lacks. On the other hand, I think that whatever code an automated designer generates will be horribly bloated. And who will be able to write XAML by hand?

One of the chief points of XAML being an XML-based markup language is so that peple can actually author it. My personal opinion is that this is more of a bad thing than a good thing, I prefer using GUI tools to design a user interface than dicking around with markup files. I've always disliked technologies like CSS and ASP.NET, moving GUI programming in that direction seems to me like a step backwards but based on the enthusiasm about XAML showed by various people in the developer community it seems I am a Luddite.

The main thing I want to point out about the Diego's statements so far are that they are FUD, no designer has been demoed for XAML let alone one that generates bloated code. This is all just negative speculation but let's go on...

And: the problem of "bytecode protection" in Java comes back with XAML, but with a vengeance. How will the code be protected? Obfuscation of XML code? Really? How would it be validated then? And why hasn't anyone talked about this.

XAML is compiled to IL. XAML obsfucation questions are IL obfuscation questions. If you're gung ho about protecting your "valuable IP" with IL obsfucation technologies then grab a copy of Dotfuscator or Spices.NET.

On a related note, Robert says this regarding XAML:

[...] you will see some business build two sites: one in HTML and one in XAML. Why? Because they'll be able to offer their customers experiences that are impossible to deliver in HTML.

Come on, Robert, these days, when everyone's resources are stretched to the limit, when CIOs want to squeeze every possible drop of code from their people, when everyone works 60-hour weeks as a matter of common practice, are you seriously saying that companies will have two teams to develop a single website? Is this Microsoft's selling point? "Here, just retrain all of your people, and double the size and expense of your development team, and you'll be fine."

I tend to agree with Diego here. Having a XAML-based website on the Internet will most likely be cost ineffective for quite a while. On the other hand, it is quite likely that using XAML on the intranet will not be. Corproate intranets are all about  homogenous environements which is why you tend to see more Java applets, IE-specific pages and ActiveX controls used within intranets than on the global World Wide Web. If I was a member of the Longhorn evangelization team or any other of the public faces of Longhorn or Avalon I wouldn't focus much on XAML on the World Wide Web but that's just my opinion.

That leaves two possibilities: 1) XAML will be niche and never really used a lot (think ActiveX, or, hey, even Java Applets!) or 2) XAML will kill HTML. 

Talk about completely missing the point. XAML is primarily for writing Windows client applications, y'know like RSS Bandit or SharpReader, not for delivering stuff on the Web. I don't think anyone at Microsoft is silly enough to think that XAML will replace HTML. The idea is completely laughable.

It is always amazing seeing how stupid and arrogant people tend to think Microsoft is.

 

 

 

Halley Suitt writes

Employers are about to lose a lot of "loyal" employees who have been sticking around through the bad economy, but are more than ready to jump ship as the job market snaps back.

Business Week wrote about this in October, but I think it's coming on even stronger now. BW suggests employers are in for a rude awakening:

I get the same feeling while walking the hallways of the B0rg cube. I suspect that if this becomes a problem in the near future the B0rg will try to adapt as it always has.