incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [Proposal] Blaze
Date Mon, 24 Jul 2006 17:01:32 GMT


James Strachan wrote:
> I guess its a murky area legally - making similar APIs using
> documentation as a guide. e.g. its quite striking how many extremely
> similar APIs are in .Net and Mono to the JDK.
> 
> FWIW there's a current practice to get around Sun's bizarre licensing
> on various Java/J2EE APIs - folks type in their own version of the
> source code using the javadoc as a guide. e.g. try the
> geronimo-spec-*.jar as an Apache licensed version of the
> crappily-licensed-Sun J2EE jars. I guess thats legal right? So maybe
> just using documentation to create similar APIs on other platforms is
> OK?

That's not why people do it - they do it because until recently, Sun's
binaries for for the API classes/interfaces were available only under
unacceptable restrictive terms.

geir

> 
> 
> On 7/20/06, robert.j.greig@jpmorgan.com <robert.j.greig@jpmorgan.com>
> wrote:
>> I think there may be some legal issues with creating an API that
>> resembles
>> JMS too closely.
>>
>> From the JMS licence terms:
>>
>> "Subject to the terms and conditions of this license, Sun hereby
>> grants you
>> a fully-paid, non-exclusive, non-transferable, worldwide, limited
>> license (without the right to sublicense) under Sun's intellectual
>> property
>> rights to review the Specification internally solely for the purpose
>> of designing and developing your Java applets and applications
>> intended to
>> run on the Java platform. Other than this limited license, you
>> acquire no right, title or interest in or to the Specification or any
>> other
>> Sun intellectual property. The Specification contains the proprietary
>> information of Sun and may only be used in accordance with the license
>> terms set forth herein."
>>
>> The key bit here is "intended to run on the Java platform".
>>
>> That said there is definitely merit in having our .NET API and C++ API
>> being relatively similar.
>>
>> XMS for C# does resemble JMS very closely although with delegates and
>> with
>> the naming convention for interfaces. I am not sure whether IBM would be
>> interested in donating XMS.
>>
>> RG
>>
>>
>> |---------+---------------------------->
>> |         |           "James Strachan" |
>> |         |           <james.strachan@g|
>> |         |           mail.com>        |
>> |         |                            |
>> |         |           19/07/2006 20:50 |
>> |         |           Please respond to|
>> |         |           general          |
>> |---------+---------------------------->
>>  
>> >------------------------------------------------------------------------------------------------------------------------------|
>>
>>  
>> |                                                                               
                                             
>> |
>>   |       To:      
>> general@incubator.apache.org                                                    
                           
>> |
>>   |      
>> cc:                                                                             
                                     
>> |
>>   |       Subject:  Re: [Proposal]
>> Blaze                                                                           
            
>> |
>>  
>> >------------------------------------------------------------------------------------------------------------------------------|
>>
>>
>>
>>
>>
>> On 7/19/06, Paul Fremantle <pzfreo@gmail.com> wrote:
>> > > Currently ActiveMQ has several C/C++ clients (with another client
>> > > library waiting to get through the  donator's lawyers), so it might
>> > > make sense at some point to try unify the C++ clients together too so
>> > > users have a single C++ API for their messaging client and then a
>> > > number of implentations/transports/protocols to use at deployment
>> > > time. i.e. making a JMS for C++ API. (We've got a good start called
>> > > CMS in ActiveMQ...)
>> >
>> > I agree that a C++ (and also C) rendering of a JMS like API is going
>> > to be a very useful thing.
>> >
>> > James - do you have any idea how CMS matches or differs from IBM's XMS
>> > (
>> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html
>>
>> )?
>> > XMS is also a rendering of JMS into C/C#/C++.
>>
>> Thanks for the link! I've had a quick look and it looks remarkably
>> close to the current CMS client. Hardly surprising I guess since they
>> are both kinda clones of the JMS API but in C++ and using JMS 1.1 and
>> mostly ignoring the crappy bits of JMS 1.0.2b :)
>>
>> I couldn't see the C# client so not sure if we differ a bit there - we
>> ended up changing the C# client a little from JMS to make use of C#
>> coding conventions and features (like delegates and events etc) - and
>> we followed that sucky C# practice of naming interfaces IConnection
>> etc :). Not sure if the XMS in C# does the same. (We imaginatively
>> called the C# client NMS for .Net Messaging System).
>>
>> I wonder if IBM and the XMS folks would be interested in donating the
>> *API* code for XMS to Apache and working with other folks at Apache so
>> we can merge some of the C/C++/C# clients together into a single
>> reuable client API with pluggable providers (and maybe even some
>> resuable optional implementation code different implementations could
>> choose to reuse)?
>>
>> There's clearly a delta between AMQP and the features of JMS, but even
>> if we just get the core JMS semantics reusable across the clients it'd
>> be a big win IMHO.
>>
>>
>> > I think it would be interesting to see a confluence of the APIs and
>> > protocols between ActiveMQ and Blaze giving interoperability in both
>> > code and on the wire.
>>
>> Agreed.
>> -- 
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>
>>
>>
>> This communication is for informational purposes only. It is not
>> intended as an offer or solicitation for the purchase or sale of any
>> financial instrument or as an official confirmation of any
>> transaction. All market prices, data and other information are not
>> warranted as to completeness or accuracy and are subject to change
>> without notice. Any comments or statements made herein do not
>> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
>> and affiliates.
>>
>> This transmission may contain information that is privileged,
>> confidential, legally privileged, and/or exempt from disclosure under
>> applicable law. If you are not the intended recipient, you are hereby
>> notified that any disclosure, copying, distribution, or use of the
>> information contained herein (including any reliance thereon) is
>> STRICTLY PROHIBITED. Although this transmission and any attachments
>> are believed to be free of any virus or other defect that might affect
>> any computer system into which it is received and opened, it is the
>> responsibility of the recipient to ensure that it is virus free and no
>> responsibility is accepted by JPMorgan Chase & Co., its subsidiaries
>> and affiliates, as applicable, for any loss or damage arising in any
>> way from its use. If you received this transmission in error, please
>> immediately contact the sender and destroy the material in its
>> entirety, whether in electronic or hard copy format. Thank you.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message