P@ Sunglasses

All | AOP | blogs.sun.com | books | Cool | Fun | General | Java | OpenSource | Personal | Portals | Rome | Syndication | wallstreet | Weblog
« Marsedit configurati... | Main | Michael Lewcio's... »

20050426 e martë prill 26, 2005

Typology of syndication applications

rss_typology_javaone.jpg

I just sent Dave Johnson my slides for our common session on syndication at JavaOne. The first part is an introduction about syndication history, formats and standards. I've given similar talks many times for the past 3 years and always had too many slides. This time I concentrated on a typology of syndication applications, and reduced my 10 slides on the topic in a single graphic. This typology is based on technical characteristics, as opposed to the typology used by business people or VCs to partition these applications. If you want to read a more business oriented analysis I recommend Richard McManus' comments about the JupiterResearch report on RSS readers, and Brad Feld's thoughts about why he's hot on Feedburner, where he identifies 8 segments for RSS and blogging applications (Brad is a VC who invested in FeedBurner, Technorati and NewsGator).

Partitioning syndication applications based on their technical characteristics, client vs server, producer vs consumer, helps to highlight where the opportunities in this space are, from a technical perspective (after that you need to find the business model that goes with it:-).

My own take on it, and what I've been advocating at Sun for the past year, is that the biggest opportunities are on the horizontal axis, ie applications that both produce and consume syndication formats.

On the client side I call these Desktop Syndication Suites, examples being the venerable pioneer Radio UserLand, and the newcomer dynamic duo NetNewsWire + Marsedit on the Mac. I expect Office Suites (Open Office, MS Office) to follow this trend and integrate an aggregator and a feed producer.

On the server side I call these server side filters Server Syndication Engines. Examples are the grandfather O'Reilly Meerkat, that I use since a long time to filter out O'Reilly feeds, Feedster, oriented on search, Feedburner, oriented towards publishers, and AllConsuming which provides topical aggregation based on books. I expect this last category to grow a lot in the next few years. One of the category of software that will merge with this one is server side aggregators: today they are sinks for feeds, they read all, and spit it out in HTML for browser clients. I think they will evolve into server side filters, letting you consume feeds in feed readers (it could be client side, but also other server side readers or filters). Bloglines/NetNewsWire feed synchronization is a first step in this direction.

The other trend I talk about in my JavaOne presentation is syndication formats as a universal envelope format for time based queries. What this means is that for many web services application, when the operation is a query type, the envelope format won't be SOAP but Atom or RSS 2.0. The payloads will be embedded as namespaced extensions under the entries. The next evolution in syndication applications is UBL embedded in Atom! This is for this type of application that we built the modules support in our ROME library. Amazon's recent OpenSearch standard, where they added 3 elements to RSS 2.0, mainly for managing result pagination, in order to aggregate search results from various engines on a9, is a first step in that direction. I will also expand on this theme at our Xtech 2005 presentation in May (this time with Alejandro only).

Crazy ideas? Comments are welcome.

( Pri 26 2005, 08:53:24 PD PDT ) Permalink Comments [3] Chat about it Technorati cosmos Tagsurf It

Comments:

While not necessarily breaking the generalized topology, I think it is also interesting to note Podcasts and TorrentCasts that use RSS as an intermediary layer for driving what is a really signifigantly different application topology. At a certain level it really is about the nature of the Syndication feeds themselves: as a dual-use meta exchange system and an actual content exchange system. Certainly in the case of Bloglines or Sage, the syndication itself is a content exchange "protocol" vs a "notification event". I think moving forward it is likely we will see these two modes of thinking further fragment. As the Atom protocol spec comes to fruition, the "syndication" transcends "content exchange" to become and API, meanwhile enclosure wrapping and smart subscriptions for meta services are infiltrating more applications. Media devices in particular, but it becomes part of the larger Semantic Web(tm).

Posted by kebernet on prill 26, 2005 at 09:40 PD PDT #

Very good comment Robert, I see the content vs notification, or content vs meta data, aspect of syndication application as being a third axis. I agree that it will be a growingly important one. I need to update the model to include this third axis (difficult to diagram in 3D:-)

Posted by Patrick Chanezon on prill 26, 2005 at 09:51 PD PDT #

Re: Open search and search engine results

It's actually the OpenSearch Description Document (http://opensearch.a9.com/spec/opensearchdescription/1.0/) that provides the most useful pagination information, and that isn't RSS. In some ways Nutch's proposed approach (see http://issues.apache.org/jira/browse/NUTCH-42 and the mailing list archives) is more useful because the URLs for pagination are embedded in the results.

Either way, using RSS/Atom as a search result medium is a big win. Atom/RSS support (and ROME!) lets me support new search engines in Argos as easily as the MSN Searcher

Posted by Nick Lothian on prill 26, 2005 at 04:39 MD PDT #

Post a Comment:

Comments are closed for this entry.

Valid HTML! Valid CSS!

This is a personal weblog, I do not speak for my employer.