Atom over XMPP

I'm currently experimenting with the idea of using Atom over XMPP, at a minimum to push out a pointer to an entry behind a firewall into a more public staging area.

The thought would be that the Atom "pointer" to the entry is pushed into the public space, and when a client of that entry wants more detail, there is an XMPP service associated with the entry that can be used to retrieve the details.

Exactly half of me thinks that this is what Atom was meant to do - get the notion of an entry out there with enough information to make a decision about weather you want the detail, and let the interested parties decided if they want to fetch the remainder. The other half thinks that this is just the geek in me wanting to use Atom when there really isn't a need for it and that XMPP and less-structured XML stanzas can work just fine, that I can demand pull the list of entries when needed as well as the details.

There are some general rumblings out there on the interwebs, but no great success stories. Anyone care to share?

St. Peter seems to be thinking along similar lines. I would love to hear some real-world usages before I'm sold on Atom in this context.

Update: ralphm points to a newer draft on xmpp.org. Thanks!

Having and Eating Cake

Fuzzy asks about options for disconnected client alternatives.

I started a reply, but it got too long so I decided to post and link instead.

I've now done this analysis a few times for a few different scenarios and as with most things, the devil is in the details. At the end of the day, although not quite so dogmatic, what usually matters most is ease of programming and that is generally driven by your server-side. It probably shouldn't be so, I'd love to say "Just put a set of RESTful services out there and I'll handle the client thanks", but in reality the separation is rarely that clean with more rich (i.e. offline) clients.

Fuzzy asks about a couple of technologies that I've worked with and others are mentioned in the comments.

I'd stay away from Tibco GI if you want to have any hope for advanced functionality like offline access, XMPP or direct socket manipulation. More rich APIs are available in XUL and AIR if you need to go there, and when I last worked with GI it was quite brutal (I.E. for development environment, no FF support, massive code base). Most of these have changed, but I feel like with something like GI, it almost doesn't matter that it's BSD licensed, you won't be able to grok or change the code anyway, it's too complicated and if you need what it does, you are almost certainly pounding a square peg into a round hole.

In the comments, Brian advocates a combination of Gears and GI - that scares me to death. Two technologies that have no knowledge of each other using the browser as a binary integration bus via JavaScript - I've yet to see that work on any effort of size and it's bound to cause some serious headaches, especially when you can't control what a user does from either side of that integration. Doesn't pass my sniff test.

Most importantly thought, I'd look at the community story there, it's not very compelling. GI strikes me as almost abandon-ware by Tibco and seeing as how they were so late to the OSS game, I have doubts about their commitment to sustain the community. Conversely, AIR has far more momentum and Adobe worked hard towards building community from the beginning.

For what it's worth, when I was talking with Tibco about these concerns and pressing them to open the code, they laughed and told me it would be really expensive. Guess I was on to something. I'll continue hammering Adobe to do the same with the Flash Player with every opportunity I get.

Having worked with XUL, I found it quite painful. The entire effort is under-documented to say the least. For Fuzzy's purpose, it obviously Mozilla-specific which may or may not be an issue. I can't say I've ever seen anyone build anything with any serious eye candy on XUL, just basic chrome and mostly tree views. If you have half an inkling that you might need some eye candy to sell your product, XUL probably isn't for you.

More importantly though, If it doesn't meet your lower-level needs for things like images or networking, be prepared to write some cross-platform C++ and COM-like IDL. You will also need to deal with version differences (i.e. XUL on FF 1.5.x is not the same as in FF 2.x). That said, if made to choose between GI and XUL, I choose XUL.

My personal bias is still for AIR. The community has good momentum, programming model is the most simple of the other options (including Sarge's Tcl comment - have fun with that return to DLL-hell). Not open though, so if you go that route make sure it's critical to your story and that open-ness is not.

Lazlo can "compile" to Flash as Mike W. mentions in Fuzzy's comments, but can also remain in AJAX/DHTML land if you so choose - Flash simply performs better. In all the testing I've done, Lazlo will not perform consistently nor render consistently if you do not transform to FVM bytecode, so those are likely not options.

One other potential option is haxe. Saw a presentation on it at OSCON a few years ago, seemed like a solid technology but hasn't really caught on in the states anyway. It's been around for several years now and people who use Neko seem to love it. Can't speak from experience with that one, but I'd give it a look.