[Standards-JIG] JEP-0060: Comments on latest draft.

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Fri Jun 25 23:30:55 UTC 2004


 

> -----Original Message-----
> From: Bob Wyman [mailto:bob at wyman.us] 
> Sent: Friday, June 25, 2004 7:03 PM
> To: Fletcher, Boyd C. J9C534; 'Jabber protocol discussion list'
> Subject: RE: [Standards-JIG] JEP-0060: Comments on latest draft.
> 
> Boyd Fletcher wrote:
> > I believe JBI is using Sun's Java Messaging Service PubSub 
> API which 
> > isn't proprietary
> 	Sun's JMS API *is* proprietary. It is defined by Sun. 
> It is *not* the result of an open process and its definition 
> is controlled by a single vendor.

actually the Java Community Process (www.jcp.org) defines what is and is not JMS. Sun is a member of that process. Though the JCP is not a perfect process it as much of a standards organization as the ISO,W3C, ITU, and OASIS. All of which are also membership based.


> 	Also, JMS only specifies a programming interface. It 
> does not specify a transport protocol. The result is that 
> virtually every JMS implementation uses its own protocol to 
> move stuff below the API. The result is a lack of 
> interoperation between JMS implementations by different vendors
> -- unless you build in gateways. Thus, using JMS, you might 
> be able to move code between two implementations -- but you 
> often can't move messages.
> 	It would be useful to define an XMPP API so that we 
> could have an alternative to Sun's proprietary JMS API...
> 	In any case, the JBI stuff is supposed to be based on 
> CAPI[1] which is usually layered on JMS.
> 
> > The biggest problem we are having at the moment is the bandwidth 
> > utilization of XMPP is higher than IRC so we are looking at ways to 
> > compress XMPP packets.
> 	This is a general issue that plagues every high-volume 
> XML based system. The "solution" to the problem may come from 
> the W3C's "binary XML"
> investigations. At PubSub.com we mitigate these problems by 
> converting all the XML to a highly efficient and highly 
> compressed binary format which is defined by ASN.1. We use 
> binary internally. We only use XML in external interfaces.

unfortunately they don't have a specification yet and they aren't even sure they are going to.


> 		bob wyman
> 
> [1] http://www.infospherics.org/api/CAPIv1_0/javadocs/
> 
> 
> 



More information about the Standards mailing list