qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: qpid broker on windows
Date Sun, 01 Feb 2009 02:04:44 GMT
S Sudhakaran.m wrote:
> >What implementation is provided for these abilities in the spec is up 
> to the implementer
>  
> Thanks for the reply Carl.
>  
> But can't the standards body decide what are the must features and 
> standardize on them ?
>  
> I have no experience in standards process but, really, what prevents 
> an Apache flavour of AMQP / IBM flavour of AMQP / OpenAMQ flavour and 
> so on and so forth? In which case, the very intention with which AMQP 
> was concieved in the first place by OHara, to make messaging a 
> commodity software, is lost ?
>  
> The reason i'm evaluating AMQP instead of any other solutions is also 
> primarily due to this open-nes and secondary to the features, which i 
> admit are great too. However a feature progression from great to heavy 
> i admit would be percieved as a disadvantage - like say the CORBA  ?
>  
> Is it possible to make things stricter, as a legal binding on part of 
> the AMQP implementors to use the term AMQP as a binding to implement 
> all features (okayed by a freely available set of tests) or not claim 
> AMQP compatibility at all?

Agree, early versions of the spec where not clear enough between MUST, 
SHOULD and MAY, with Qpid implementation covering the specification the 
best to date. This is a clear danger, and one of the things the AMQP WG 
needs to be very clear on when they publish 1.0

What is interesting is that for example the extension points in AMQP 
0-10 are actually well thought out. For example applying a queue size 
limit in Qpid is done via the fieldtable on queue declare. and when the 
limit is reached, a reject is sent. What is interesting is that any AMQP 
0-10 client can fully interop with this size limited queue, because from 
the client side it is 100% AMQP compliant. Actually very well thought 
out. I see less danger in this area, as opposed to the specification 
being miss-interpreted, or interpreted differently.  These are the areas 
that need to be nailed closed in the 1.0 specification. One such example 
is a debate Gordon & I had on the Rabbit list with the implementers of 
that broker, where they where trying to make the point that as the 0-8 
spec did not have the word atomic in it, they did not implement (TX) 
transactions atomically. i.e. they have non-atomic transactions... 
(Personally I don't know what a non atomic transaction is)

So, hopefully there have been enough such debates that the AMQP WG can 
close these ambiguities in 1.0, or at least the critical ones, so we can 
all have an ecosystem of commodity messaging.
Carl.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message