P@ Sunglasses
e martë prill 26, 2005
Typology of syndication applications 
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
Tagsurf It
e enjte qershor 17, 2004
The rich client/thin client debate As I explained in a previous post, last week BEA's Adam Bosworth unveiled his Alchemy intelligent caching framework.
John Udell who's been playing at the limits of browser based XML applications since a long time, is bullish about it, in Thin clients and rich data - BEA's Alchemy promises mobile users a blend of browser-based ease and rich functionality. It seems like Alchemy is going to be open source: I look forward to get the bits and play with it!
At the same time, Mozilla's Brendan Eich defines the goals and requirements for Mozilla 2.0 Virtual Machine.Back to the more programming-language-specific points above: comments welcome on realistic candidates. Obvious and controversial possibilities include Mono, Java (if open source), and Parrot (last I looked, *way* too Perl6-focused, not very mature, not looking likely to mature quickly).Wouldn't it be ironic if Mozilla's VM is Mono so that the main language for Mozilla apps would be C#? I sincerely hope it will be java. Then Joel Spolsky published a long and thoughtful essay, How Microsoft Lost the API War, where, when talking about web applications vs rich client he says:
It's this last problem that BEA's Alchemy is tackling. Add to this a solid VM in Mozilla, and good SVG support, for richer browser based applications and you have a decent alternative to the return of the rich client that Microsoft is pushing with .NET. Interesting times. ( Qer 17 2004, 04:16:30 MD PDT ) Permalink Chat about itBut there's a price to pay in the smoothness of the user interface. Here are a few examples of things you can't really do well in a web application:
- Create a fast drawing program
- Build a real-time spell checker with wavy red underlines
- Warn users that they are going to lose their work if they hit the close box of the browser
- Update a small part of the display based on a change that the user makes without a full roundtrip to the server
- Create a fast keyboard-driven interface that doesn't require the mouse
- Let people continue working when they are not connected to the Internet
Tagsurf It
This is a personal weblog, I do not speak for my employer.
