qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Fw: JMS like API for C++
Date Thu, 21 Sep 2006 00:05:44 GMT
This is really interesting.

Because there is IBM's XMS specification as well, which we politely asked if
we could use (given its a direct mapping of JMS API's to C++ API's). They
stated that they would liked to have helped but were not an a position to
sublicense the technology.  We also asked some people at Sun.

Once you have asked, and been declined, you cannot do.

One big thing about AMQP is that all the "intellectual property" around it
and QPID and iMatix's OpenAMQ is that it is being careful to stay
untainted.  It's the same reason I'm personally very uncomfortable with what
Mono is doing, no matter how cool it is.

On a different strand - there is also the fact that while JMS is obviously a
very important API for the Java community it makes a lot less sense in other
languages.  It's not even a great API to talk to middleware with, which is
why people using MQ series used the native Java binding for so long (and
still do).

So for C++, Python et al, why not do (dare I say this) a little bit better
than JMS?
A year ago, people would have called me a heretic for saying this, but look
at those people over at Spring proposing better ways to access messaging.
>From what I hear there is a lot of agreement with the sentiment.

I would assert that AMQP is cleaner than JMS; when we sort out the last
niggles in the exchange/queue/binding arrangement you will have a very nice
abstraction of middleware.  No one who have reviewed the spec dislikes that
setup.  Dare we surface it into the API?

I think yes - it makes a whole lot more sense to send a message to an
exchange than to send it to a destination.  And that's the way the internet
and postal services work too (you can give your parcel to DHL or FedEx or
whoever) and indeed stock exchanges.  What you don't do is give your parcel
directly to the destination address :-)

For Java there has to be JMS -- but why limit other languages?


On 21/09/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> On 9/20/06, Robert Greig <robert.j.greig@gmail.com> wrote:
> > On 20/09/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> > > Remember that the specification != javadoc that is available.
> >
> > Yes, I realise that. Are you claiming that you have never read the JMS
> > specification pdf?
> >
> > > > The issue of re-implementing the APIs is a completely separate
> topic,
> > > > related (I believe) to permitted uses described in the licence you
> agreed
> > > > to when you downloaded the JDK.
> > > >
> > > I think that the Geronimo JMS API that was developed at Apache we as
> > > done just using the javadoc as the reference.
> >
> > OK, but in the Sun JDK licence it states:
> >
> > "D.  Java Technology Restrictions.  You may not create,
> > modify, or change the behavior of, or authorize your
> > licensees to create, modify, or change the behavior of,
> > classes, interfaces, or subpackages that are in any way
> > identified as "java", "javax", "sun" or similar
> > convention as specified by Sun in any naming convention
> > designation."
> >
> I don't think we are doing anything of the above.  We are not
> specifying any of the C++ stuff as bing JMS.. We call it CMS.  They
> fall in a 'cms' namespace thus I don't think the above clause applies
> since our stuff is in no way 'dentified as "java", "javax", "sun" or
> similar convention as specified by Sun in any naming convention
> designation."
> > I believe this is the issue that also affects people who might want to
> > work on e.g. GNU Classpath.
> >
> > > So I think it would be VERY hard for sun
> > > to argue that a C++ api for ActiveMQ in in violation of any copyrights
> > > or licenses.
> >
> > I think they would only have to show that you have at some point read
> > the JMS specification, and using Google I was able to find fairly
> > compelling evidence that you have.
> >
> > For example, in your blog post of 21 June 2006 you state: "In some
> > cases the JMS spec requires messages to be sent synchronously". And in
> > a thread linked from the comments on that blog post you state:
> >
> > "I just reviewed the JMS 1.1 spec and section 4.10 seems like the most
> > pertinent to this discussion."
> >
> I'm not saying I never read it :) I'm saying that the folks that
> created those APIs may not have read it.
> > In any event, I am only taking advice from our legal counsel. I have a
> > duty to the shareholders of JPMC and cannot therefore ignore the
> > advice of our legal counsel even if I happened to disagree with it
> > (not that I am really qualified either to back up or refute that
> > advice).
> >
> Yep.  I'm in the same boat.  But I also don't want to shy away form
> implementing something worthwhile unless the subject is well explored.
> Does anybody know what the mailing list is that the Apache legal
> folks chat on?
> > I should point out that I find that clause in the JMS specification
> > licence really frustrating!
> >
> I think those kinds of clauses are all over all the Sun APIs.
> > RG
> >
> --
> Regards,
> Hiram
> Blog: http://hiramchirino.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message