[standards-jig] JNG Ramblings.

Iain Shigeoka iain.shigeoka at messaginglogic.com
Mon Aug 12 17:34:03 UTC 2002


I agree that binary formats may be difficult to support in some lightweight
languages.  I haven't seen any responses though so I wonder if it is much of
an issue.

I'd prefer a really light weight method of discovering the supported framing
technique rather than using multiple ports.

Perhaps a magic byte preamble.

The first byte is an ascii readable character signals original Jabber
streaming XML.  This is backward compatible with Jabber.

The first byte is 0x07 (the beep or bell character - ^G) indicates BEEP
transport

The first byte is 0x01 (start of header - ^A) indicates Mike's binary
transport

The magic start bytes can be registered with the JANA and allow transport
independence, with the same JNG XML protocols and binary data riding on top
of it. 

If the server doesn't support the transport, it sends a a Negative Ack
character (0x15 ^U) then shuts the connection (if there is a connection to
shut). 

One nice consequence is that you could connect to JNG and choose an optimal
transport depending on the data you're exchanging (e.g. Broadcasts or
streaming might use some something like quicktime, or a custom UDP API, we
could start to support native SMS traffic, etc).

It would also allow the open source survival of the fittest philosophy of
providing options and letting the most popular "win".

One major problem is that if we don't define the transport, then we can't
rely on any transport properties (ordered packet delivery, packet integrity,
etc) unless that is specified as a transport requirement.

-iain

On 8/9/02 12:11 PM, "Adam Theo" <theo at theoretic.com> wrote:

> I think this is a good point, Matthias. Is anyone aware of any other
> non-traditional programming/scripting languages (such as web-scripting
> languages) that it may be more difficult to suppport a binary wire
> protocol in? Excluding these niche languages would be a bad thing, I think.
> 
> It seems there are inherent pros and cons for each way, and each way has
> it's own exclusive uses which the other cannot mimic effectively.
> therefore, would it be possible to create two framing protocols? One
> binary, one XML? Each would run off different ports for JNG/Jabber 2.0.
> Connect to port (example) 8440 for XML, and 8441 for binary. Not a great
> solution, but it solves for both needs.
> 
> Matthias Wimmer wrote:
>> But you have to implement it first. On Wednesday I visited a friend that
>> is a Flash programmer. He wanted me to show him how to use Jabber
>> because I wan't to use Jabber for some projects. That was cool, we had
>> written a Flash Jabber client with presences, roster and all what you
>> have in a basic client within less then one your. We could just use the
>> XMLSocket class that is a standard part of Flash. - If we would had to
>> implement the framing first, it would have been impossible to get a
>> working client that fast.
>> 
>> <OT>
>> What is the Flash support in the Jabber server for? We havn't needed
>> something special.
>> </OT>




More information about the Standards mailing list