now with Atom support: java google feeds bridge

After last week's experiment of a Google-RSS bridge in Java, I took the next step and decided to check out how hard it was to generate a valid Atom feed as well. The result is an update on the Google bridge page and new code.

The idea, as before, was to write code that could generate valid feeds with as little dependencies as possible (It might even be considered a quick and dirty solution). For reference I re-checked the Atom Wiki as well as Mark's prototype Atom 0.2 feed. In the end, it worked. Adding support for Atom begged for some generalization and refactoring (which I did) but aside from that adding Atom support took a few minutes. Here are some notes:

• ISO 8601 Dates are terrible. I'd much rather Atom had used RFC 822 dates, which are not only easier to generate but way more readable. It's true, however, that once you have the date generator working it doesn't matter. But boy are they a pain. I put forward my opinion on that when date formats were being discussed, but I didn't get my way.
• I was confused at the beginning regarding the entry content, particularly because of the more stringent requirements that the feed puts on content type. For example, the content of an entry must be tagged with something like "<content type="text/html" mode="escaped" xml:lang="en">". Now, I must be honest here: about a month ago there was a huge discussion on the Wiki about whether content should be escaped, or not, and how, but I didn't think it was too crucial since, on the parser side, which I added way back when in July to clevercactus, it's pretty clear that you get the content type and you deal with it. But I was sort of missing the point, which is generation. When generating... what do you do? Do you go for a particular type? Is it all the same? Would all readers support it? The pain of generating multiple types would seem to outweigh any advantages...Hard to answer, these questions are, Master Yoda would say. So I went for a basic text/html type enclosed in a CDATA section. (Btw, enclosing in CDATA doesn't seem to be required. The Atom feed validator was happy either way).
• Another thing that was weird was that the author element was required, but that it could go either in the entry or the feed. I understand the logic behind it, but it's slightly confusing (for whatever reason...)

Overall, not bad. But Atom, while similar to RSS, is more complex than RSS. While I have been able to implement a feed that validates relatively easily, it concerns me a bit that I might be missing something (what with all those content types and all). Maybe all that's needed is a simple step-by-step tutorial that explains the "dos and don't dos" for feed generation. Maybe all that's needed is a simple disclaimer that says "Don't Panic!" in good H2G2 style.

Is it bad that Atom would need something like a tutorial? Probably. Is it too high a price to pay? Probably not. After all, more strict guidelines for the content are good for reader software. I thought "maybe if there's a way to create a simple feed without all the content-type stuff..." but then everyone would do that, and ignore the rest, wouldn't they.

Of course, maybe I misunderstood the whole issue... comments and clarifications on this area would be most welcome.

I guess there's no silver-bullet solution to this. The price of more strict definitions is loss of (some) simplicity. The comparison between a language with weak typing (say LISP) and one with strong typing (say, Java) comes to mind when comparing RSS and Atom in this particular sense. I think that I would go with RSS when I can, since it will be more forgiving... on the other hand I do like strong typing. But should content be "strongly typed"? I'll have to think more about this.

Interesting stuff nevertheless.

PS: there's a hidden feature for the search. It's a hack, yes. It might not work forever. Still worth checking the code for it though :-)

now preparing...

...for a feature-freeze in clevercactus and the subsequent bugfixing only period prior to final release. Part of that is installing a bug tracking system, and I'm now looking at bugzilla, scarab, FogBuz and JIRA. I've used scarab internally up until now, but I want to deploy this in the open and I'm not too happy with Scarab's complexity. FogBuz looks nice and its price is reasonable, although if I'm not mistaken it is fully hosted (an ASP model) for the trial and requires Windows if deployed, which wouldn't work for me. JIRA looks nice, but I wonder if I could use the trial as I want to. Bugzilla might be the way to go then; only problem is that the setup is a complete nightmare. We'll see.

the mobile platform wars

So it only took a couple of days since Motorola bailed out of Symbian for a rumor to surface that they would be releasing a "Microsoft-powered" phone, sold through Orange, later this month. Recently there was another rumor (or news? I can't find a link) that Psion was moving to WinCE for its mobile devices. In the meantime, Linux is making inroads into all sorts of devices. Oh, and, by the way, PalmOS is down but not out yet.

See a pattern emerging here?

Call it the mobile platform wars. In which Symbian has the tactical advantage, but is, strategically, in an entirely different position.

Symbian, by design, allows its licensees to tailor their offering heavily for different devices, which is great for licensees short-term (allows them to obtain early lock-in on features), but not so great for Symbian as a long-term platform. Long term, a platform cannot survive like that, and by extension neither can its licensees. The platform splinters irreversibly, because even though the licensees achieve short-term early lock-in on features, the platform itself has no lock-in.

Symbian won over Palm through faster innovation and larger deployments, but now Symbian is the incumbent, and the game is different. The new entrants are not competing on features, but on platform homogeneity.

It has happened before: Look at UNIX in the 80s.

In theory, you could port applications between UNIX OSes by sharing more than 80% of the code between them through a "standard" called POSIX.

In practice, almost no one did it.

And so the POSIX-UNIX "standard" allowed itself to be overtaken by both Linux and NT. Because once platforms are established, it all goes back to third-party developer support. Why? Because users care about applications and devices, not about OSes. They don't care if, say, the memory space is 32-bit flat. Developers do. Which is why third-party development should be active and growing for any long-term platform.

Which requires a vibrant community. Which requires tinkerers and small developers, as well as big developers. Which requires simplicity and portability within the platform, and a low-cost of entry (read: free, well-documented, well-supported, entry-level tools).

And is it a coincidence that, again, both a Windows variant and Linux are emerging as the greatest threat to an innovative platform? I don't think so.

Netscape, by the way, made similar mistakes with regards to developers. And they played a small but important role in their fall from grace.

But Symbian is improving, and listening. It isn't over. Yet.

Even if it comes to the worst, I can't see Symbian ceasing to exist. When you're talking about millions of devices sheer volume wins, so it's quite possible that in one or two years Nokia will just end up owning Symbian outright and it just will be Nokia vs. Microsoft.

But since Nokia is one platform and one vendor, Java would be a better choice.

Paradoxically, excellent Java support might allow Symbian to prosper by providing the best Java mobile platform around. Palm might yet come around as well and figure out that Java is their best weapon to fight the Microsoft/Linux juggernaut.

And in that case, once again, the only thing standing between us and yet another monoculture would be that sweet smell of digital coffee.