qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Compliance Test Suite
Date Thu, 26 Oct 2006 09:47:48 GMT
On 10/24/06, John O'Hara <john.r.ohara@gmail.com> wrote:
> James
>
> AMQP is supposed to be "a message provider *protocol*" just like SMTP, or
> NFS are protocols. They achieve a goal simply and well in a manner which is
> broadly accessible.
>
> So imagine for a moment you wanted to write an NFS server for an IBM
> mainframe.  Mainframes have lots of interesting notions about how files are
> structured, accessed, secured etc, but to make a working NFS server you'd
> need to ensure that all of the concepts in NFS like an IP transport, a
> directory hierarchy, POSIX style permissions and filename character sets
> were all perfectly mapped.  Some of these concepts might not even exist on
> source platform, and you'd have to implement them.  But you'd do it, because
> you know that your clients value compatibility with standards highly.
>
> The same is true of anyone implementing AMQP.  They may be adding it onto an
> existing, perfectly fine implementation.  But that existing codebase needs
> to be modified, perhaps quite a lot, to meet AMQP semantics; or clients
> won't be interested.
>
> To quote you,
> "its more a case of making some new messaging providers that speak the same
> wire protocol?"
>  Whole new products - no; but a lot of modifications may be required to
> existing brokers to achieve good compatibility - just as mainframes took
> modification to support TCPIP.

Thanks for the heads up.


> If you know of an easier way to plug-and-play wire-level interoperability
> without compromising functionality, I'd love to hear it.

Its a classic tug of war between functionality, performance,
complexity and interop. It depends where on that continuum you're
aiming for what your ideal solution will look like.


> I proposed that the AMQP Working Group create an interoperability subset of
> AMQP (let's call it AMQP-lite).  This would be just enough to login, publish
> to and consume from queues.   It would be easier to retro-fit onto other
> middleware, but would have to be an lowest common denominator solution.
> Would you like to help in such an effort?

I'm afraid I've enough on my plate right now :) I think with AMQP,
Stomp, XMPP, Cometd, REST, OpenWire and WS-N/WS-E/WS-RM we've enough
protocols for now :)

FWIW Stomp has proved itself to be excellent at the low end; where
ease of use & simplicity of the client outweighs the performance gains
in having a much more complex binary protocol. Folks can literally
write a client from scratch in an hour or two - or just use telnet :)
So it comes from the HTTP school; make clients really easy to write &
brokers fairly forgiving but a good server might take a while to write
:)

If someone ever had enough time on their hands I guess we could come
up with something in between Stomp and AMQP though am not sure if its
worth it; if folks care about simplicity & easy interop, they'd maybe
go with Stomp - if they wanted performance & functionality they'd go
with AMQP so am not sure who'd go for AMQP-lite.

Maybe we just need to make sure AMQP remains nice and modular like
XMPP is; with as small & simple a core as possible with then different
functionalities layered on in separate optional modules?

-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message