Martin Ritchie wrote:
2009/2/5 Rafael Schloming <rafa...@redhat.com>:
Robert Greig wrote:
2009/2/3 Rafael Schloming <rafa...@redhat.com>:
I could buy into s/M/0./ for everything (but not s/M/1./). I know some
people are opposed to releasing 0.x versions for marketing reasons,
but that essentially removes any useful information from the rev.
I agree, and personally I don't think marketing should enter into the
version number discussion. I think once you let marketing in, you've
removed
all hope for sane and useful version numbers. ;)
I don't think the 1.x argument is about marketing, really. It's about
conveying information that reflects accepted understanding of the
meaning contained in the number. A 0.x release implies to many people
a low level of maturity and stability. Certainly looking at the Java
broker and client, only because I a most familiar with those, I know
that they have many production installations today delivering
business-critical messages. By labelling that 0.x I think it is
painting a false impression of the maturity of the software - which is
now several years old. Are we really saying that after three years
qpid isn't even 1.x?
I do also agree that 1.x implies a certain level of API compatibility
- but I can smugly say that I have consistently argued on this forum
that building an API that is closely tied to AMQP is insane. Maybe
this implies that for the next release the non-Java languages need to
focus on the API design. Or we should be comfortable moving to 2.x
relatively quickly as the API evolves.
If we had *some* API other than JMS then labeling it 1.x might be reasonable
even if we expect to have a 2.x coming up, but for me at least, what we have
doesn't constitute enough of an abstraction to be labeled a 1.x since that
implies we have confidence in our ability to go from 1.x to 1.x+1 without
breaking the API, and I don't think we're there yet.
I think if you're concerned with the 0.x moniker implying instability then
maybe we should stick with Mx and make it a high priority to build out the
non Java client APIs.
I'm +1 on that.
Implementing an API that exists on each platform for messaging seems
like the way to go.
Obviously only if there is such an API. I know at least C# has a
standard System.Messaging but does Ruby, Python and C++ have simlar
platform Messaging APIs?
I don't think we should be making one up, especially as some of us our
JMS API tainted.
I'd say the best way to go is to reuse already well known and accepted
APIs where we can. Is someone willing to look in to what APIs we could
use?
I can't comment on C++, but as far as I know there isn't any sort of
standard messaging API for python or ruby. I think a reasonable approach
for both python and ruby would be to take the basic nouns and verbs from
JMS (Connection, Session, Producer, Consumer, Message), and hang them
together in a similar manner to JMS, but use appropriate idioms from the
respective languages.
I don't know about the implications of this approach relative to
JMS-taint, but I know python standard library has done similar things
with other Java APIs, e.g. the python threading module.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
