[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 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
>  http://www.infospherics.org/api/CAPIv1_0/javadocs/
More information about the Standards