Re: [ogpx] content negotiation for LLSD over HTTP connections

[Carlo Wood <[e-mail]>]

On Fri, Jun 26, 2009 at 04:48:00PM -0700, Infinity Linden wrote:
> so... we have three serialization formats for LLSD messages over HTTP:
> XML, JSON and Binary. each has it's own uses and constituency.
> 
> but it _does_ leave implementers and deployers with questions like:
> 
> * must i support each and every LLSD defined serialization?
> * under what circumstances should i choose one over the other?
> * what if i am a server and i only want to use one serialization?
> * what if i am a client and i only want to use one serialization?

In the past I designed a client-server protocol negotiation sheme
that allows for arbitrary protocol enhancements over time, without
an every growing protocol negotiation payload or the need to
keep supporting legay protocol; namely, it is possible to shift
the 'base' protocol and drop support for (very) old protocol.

This sheme was originally written for IRC, and wasn't adopted
because the people who had to decide if they liked it weren't
able to understand it... and lacking an overview, it gave them
the uneasy feeling that it was "too complicated".

However, it is not too complicated at all. It's mathematically
perfect and rather easy way to allow for protocol changes in
the future.

One part of it involves negotiation of optional (non-mandatory)
features / protocol aspects, so you could use it for example to
negotiate the serialization in the case that both, server and
client have their preferences and/or limitations.

Basically, it works as follows:

The client connects and "requests" a protocol (version) and
specific features. The server then has two options: either
it tells the client that it is incompatible (too old), or
it sends back the set of feautures that will be used.

The details can be found here (though be warned, this is my
original design and applies to IRC):

http://www.xs4all.nl/~carlo17/irc/prot.html

-- 
Carlo Wood <[e-mail]>

PS Don't tell me it's "too complex" ;).
   This is a very flexible, very powerful way to make sure
   that grids being developed by different groups will not
   be get stuck in some legacy protocol.