qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Fw: JMS like API for C++
Date Thu, 21 Sep 2006 01:18:43 GMT

I also support that we should stay clear of JMS API for non Java AMQP 
APIs and have a
crack at something better. Take a look at the Python, everyone that has 
so far seems to love it.

Carl.

John O'Hara wrote:
> 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?
>
> Cheers
> John
>
>
> 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
>>
>


Mime
View raw message