e hënë janar 10, 2005

We're nearing a beta for ROME, so it's finally time to get serious:-) What would an open source project be without a preso and a T-shirt?

I finally posted the presentation I gave at a Sun internal open source summit this summer, plus the T-shirt I designed for the event.

The presentation is on the ROME Wiki, in PDF or Staroffice form: feel free to reuse it if you want to present ROME, and enhance it. It was designed for ROME 0.4, so it may need a bit of updating.

The T-shirt is just a quick fun image I hacked before taking the plane last summer: a project isn't real until you get the T-shirt:-) You can use the image at the top of this blog entry and iron it yourself, which I did, or use my CafePress shop to get it.

When we started the ROME (Rss and atOM utilitiEs) project last may, we had done a preliminary review of existing syndication libraries in java, and none of them suited us: we try to avoid the Not Invented Here syndrom as much as we can:-)

The other day Kevin Burton commented about our Xtech 2005 article submission about Rome that he would submit a paper as well about Jakarta Feedparser. We were not aware of this project when we started Rome: it's hidden in the bowels of the Jakarta Commons Sandbox (I think I did a quick search on apache rss at that time and found nothing meaningful: Google makes you lazy!). Too bad because it looks pretty good. And this is not surprising because Kevin is the guy who created this very innovative aggregator called NewsMonster a few years ago (what i thought about it in my very old weblog, and my old weblog), and started a more promising online aggregator implementing the same ideas (collaborative filtering, reputation metrics, tagging) a few months ago: Rojo. According to the project's mailing list, Feedparser is based on NewsMonster's libs, and is what they use at Rojo.

A cursory look at Feedparser makes me think that our architectures are quite different: they seem to have an event based approach, defining SAX events at a higher semantic level (like SyndFeed and SyndEntries in ROME, but based on events at parse time), while in ROME we handle you Java objects once the parsing is over (more like a DOM-based approach). But even if the architectural approaches are different, they have a few goodies that could be useful for us, such as nice autodiscovery classes to guess where the feed associated to a page is, based on the system used to generate the feed (if people omit the RSS or Atom autodiscovery link in the template). And they could benefit from a few things in ROME, such as the fetcher, and Modules.

Also in the few libraries that we studied before deciding to create ROME, only Informa seems alive and kicking.

Joseph Ottinger who created RSSLibJ switched to ROME when we shipped 0.1, and is now part of the ROME developers, with very active contributions to the design debates we have in the mailing list. And Jason Bell decided to stop development on RSSLibJ recently and use ROME.

If you're doing syndication in Java today, you have the choice among these 3 libraries. Kevin's comment arrived at a good time: Alejandro and I are preparing a submission for a technical talk at JavaOne this year. And we're also beginning to think that for all future work on Syndication utilities (extensions, applications, rdbms mapping, etc...) it would be really cool to be able to leverage a common java representation of feeds and entries, instead of having your development tied to the library you have chosen... you see where I'm going don't you?

What I propose is to submit a joint paper to JavaOne this year, where the 3 teams will present their project, and to work together to determine where we are different, and similar. I think having a clear picture of what the various libraries' strength, weaknesses and designs are would be much more worthwhile for attendees than a single one (and I would be the first interested in such a presentation).

Then take advantage of JavaOne to host an open meeting to discuss the potential convergence points of our projects, and wether it is worth standardizing them in a JSR, something like a Java Syndication API. One of the reasons why I think such a JSR could be useful is that with the new Atom publishing API soon published, it would be good to have a common java API to get and set feeds. Dave Johnson plans to add a new ROME subproject for Atom publishing where yet a few Interfaces will be defined for a blog, blogsite, BlogEntry. It would be nice if all of our libraries would agree on common java interfaces for this kind of data so that they are interoperable.

Kevin, Niko, Pito, Joseph, DaveJ, Alejandro, what do you guys think? If you all agree, the deadline for the JavaOne call for paper in January 31st, so we have 2 weeks to produce a common outline.

calendar

search

navigation

links

rss feeds

referers

Today's Page Hits: 120