e enjte qershor 17, 2004 We're proud to announce that Nick Lothian, alias BadMagicNumber of Classifier4J fame (a text classification library, including a an implementation of a Bayesian classifier) joined Project Rome as a developer today.
Following this email:
I've been using Rome a bit since you released it, and generally I'm pretty impressed.
One suggestion I have is for support of conditional gets (see http://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rss_hackers ) and gzip encoding handling to be built into the library itself.
we've had a discussion in the Rome dev mailing list and he came up with some code to implement it. This will be structured as an external library, since many people developing their own fetcher system may want to use Rome just for the parsing and generation and we want to keep the library small and focused. This fetcher library will be part of the Rome codebase, in the modules directory, and be released on its own schedule.
We're really glad that Nick chose to contribute this to Rome: this is an aspect that was handled by Mark Pilgrim's Universal Parser Python library that we had no time to implement, and I'm sure many developers will use this to create their fetcher.
( Qer 17 2004, 04:52:31 MD PDT ) Permalink Chat about it
Tagsurf It
"we don't do our XML manually"... right... on the other hand, jdom-b10.tar.gz is a 3.4M (!?!?!) download and the jdom jar itself is 144KB... which is larger than the entire rome-0.2.jar (128KB)... what's wrong with this picture? I'm sure that you can do better than that and remove the *last* external dependency :)
# ls -la /usr/bin/ls -r-xr-xr-x 1 root bin 19084 Apr 6 2002 /usr/bin/ls # ls -la /usr/bin/grep -r-xr-xr-x 1 root bin 10232 Apr 6 2002 /usr/bin/grep
ls and grep (on my system:-) "weight" 29314 bytes.
The following utility program (shell script) weights 16 bytes.
ls -la | grep $1
Should I reimplement a custom version of ls and grep to create my utility or is it better to just reuse these "bloated" 30K of code for my 16 bytes utility?
See Eric Raymond's excellent koan about this, Master Foo and the Ten Thousand Lines.
There's nothing wrong with this picture.
Master Bar would even argue that there is no picture at all, but that's another exercise:-)
I looked at Zoe: looks really cool. I will try it out.
( Qer 17 2004, 04:37:59 MD PDT ) Permalink Comments [2] Chat about it
Tagsurf It
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
Tagsurf It
RSS aggregation, wether on the client or on the server is a hot topic these days.
I'm myself really excited about this area: this is why my team released the Rome RSS/Atom java library on java.net 2 weeks ago.
In the past few days I've seen a few posts in various weblogs or sites that point in the right direction.
My favorite is Phil Ringnalda's post That old hopeful feeling.
The main theme of the post is how badly supported republishing os done in the current crop of aggregators. I couldn't agree more. My own information consumption and generation practices have evolved with the tools I've used: I initially used Radio Userland. I used the included aggregator, that displayed the feeds in an IE browser window, and ctrl-clicked the POST button in front of all interesting entries. Then I would go through all the new browser windows, remove some of the text of the item, italicize the part I wanted to quote, add a comment in the IE only editor, then post the stuff to my Radio weblog. Then I moved to Movable Type and NetNewsWire to read feeds. Here double clicked on interesting items to read them in Mozilla or Firefox, and either use the blog poster from NetNewsWire, or the MT admin UI to post them. But as time went by I blogged less and less and ended up pushing many single links to my de.licio.us linkblog. I haven't found the perfect workflow yet, but NetNewsWire begins to show its limits, and I haven't found the perfect blog server for my personal blog yet.
One quote in his post that rings a bell for me is:
Not one of them says anything about having any real interest in the format used to deliver the feeds they consume. Why would they? That's a library function, parsing feeds and normalizing them into native data structures. It's the data that's interesting, not the format that you never see.
This is exactly why we started the Rome project!
Then Russel Beattie who's one of my favorite java bloggers, has this very good post Weblog Systems vs. Aggregators finally realizes that aggregators, especially server side ones, are the important part of the blogging toolset today, and talks about writing his own: just use Rome to parse your feeds Russ:-)
Last, at O'Reilly, in RSS: The Next Generation Giles Turnbull reviews 3 Mac OS X client side aggregators: NetNewsWire, Shrook and PulpFiction. NetNewsWire defined the genre, PulpFiction steals Apple Mail UI and adds archving, and Shrook steals Apple's iTunes UI and adds an interesting server side feed list and distributed checkin. I've tried them all, and still use NetNewsWire, but think the most satisfying solution will come from a server side solution. PulpFiction is not very interesting: a server side RSS to mail gateway will let you use your regular mail client to view feeds and apply filters. Shrook has the most interesting ideas, with keeping the feed list on the server side, but today the protocol for that is not open so you have to use their server.
This is an area where I think we're lacking a standard: I think the future is in server side aggregators, but people may want to still use their client side aggregator in certain situations. In order for this to work we need a standard protocol to reconcile feed lists from both sides. I was thinking about using SyncML for the protocol, to reconcile differences between the OPML files on both sides. I'll propose the idea to Brent Simmons, who made NetNewsWire.
( Qer 17 2004, 03:34:34 MD PDT ) Permalink Comments [2] Chat about it
Tagsurf It
Tagsurf It
Today's Page Hits: 36