The Atom Publishing Protocol has been published! It's RFC 5023, and represents a standard mechanism for publishing and editing web resources. It's a partner to the syndication format, which is RFC 4287. This may sound like a fairly esoteric topic, but it's a big step forward in standardizing publishing mechanisms: Tim Bray said on his site, "Here's the Atom dream: A 'Publish' button on everything. On every word processor and email reader and web browser and cellphone and PDA and spreadsheet and photo-editor and digicam and outliner and sales-force tracker. Really, everywhere. If it doesn’t have a 'Publish' button, it's broken." No word on whether AtomPub was published with the protocol itself.
- Posted by: Joseph Ottinger
- Posted on: October 25 2007 09:40 EDT
- Atom as the basis for publish/subscribe events model by Andr??s Gonz??lez on October 26 2007 05:02 EDT
- Re: Atom as the basis for publish/subscribe events model by Kit Davies on October 26 2007 07:48 EDT
- Re: Atom as the basis for publish/subscribe events model by Mikhail Franco on October 30 2007 03:42 EDT
- Re: Atom Publishing Protocol published! by Dave Sims on October 26 2007 11:18 EDT
Interesting news. This may be a crazy idea, but i'm searching for publish/subscribe event model to be used in a B2B network. In this network there are many B's (some use java, some .net, some, ...) so i need a interoperable, multiplatform, "standard" solution. My options are: 1) JMS -> requires bridges for impedance mismatch between different providers and not sure about how possible it is to play (publish/subscribe) with JMS in a .net environment 2) WS-Eventing / WS-Notification: inmature, overlapping and competing "standards". Not sure if the will converge. Not sure about the robustness of WS-Notification implementations (WAS, ServiceMix) 3) Atom! Yes. In my environment i think there are no "real-time" event delivering requirements, so i think something as trivial as Atom (pull model, not push) could work. Atom feeds can be created/consumed in every platform, and Atom is an IETF clearly defined standard. The problem: well, it is not designed for event processing. For example, it is not trivial/natural to know if an published event has been consumed and by whom... I don't think security would be a problem with atom. Security issues can be covered at the http level or at the xml level (XML Encryption, XML Signature). Anyone is using Atom for "middleware" purposes?
LLUP/BLIP is intended to do what you're after I think, though I am not sure how far down the road this project is. Kit
You also have the choice of XMPP (Jabber) and AMQP, which are both language- and platform-independent protocol specifications (unlike JMS). Just to give two examples written in Erlang: EAI using XMPP at Process One (home of ejabberd); and LShift/CohesiveFT RabbitMQ for AMQP. If you feel happier in other languages, check out Apache QPid. Mik
With proper respect to Tim Bray, I disagree with his idea that the main reason we don't have more blog postings in the blogosphere is "Because it’s too hard". Sure, maybe that's a partial reason, but I'd say the most important reason is that people want to polish what they say publicly to a mass audience, like an article in a newspaper. And because they don't have the time to do that, they get writer's block, or they're shy, fewer blog postings occur. Where I work, we have internal blogs where the audience is just us, so people are more free-wheeling than in our company's public blogs. More people post. They post more frequently. They post on a wider variety of topics. And there are plenty of comments. Cheers, David Flux - Java Job Scheduler. File Transfer. Workflow. BPM.