Re: [ogpx] LLIDL, LLSD, Transport

[Joshua Bell <[e-mail]>]

On Mon, Feb 15, 2010 at 2:35 PM, Morgaine <[e-mail]>wrote:

> There is no need for the LLIDL/LLSD spec to mandate any specific transport
> layer at all.  It's a higher level data specification which can work
> perfectly well over any reliable transport.  If details are provided with
> regard to one particular transport, then these should be given in a separate
> document so that a different transport can also be specified, separately,
> without requiring change to the specification document of the layer above
> it.
>

I confess, I was a little put off by this at first. Some work I was doing
with LLSD would have benefited from "naked" LLIDL descriptors, with no
semantics about traffic. But then I started reviewing the use cases for
LLIDL:

* Declaring the interface provided by a service end-point (i.e. I publish my
API defined in LLIDL)
* Validating the use of an end-point (i.e. I put a LLIDL validator in my web
service code and it flags invalid use)

In both cases, the actual verbs used are critical pieces of the API -
whether my end-point supports GET, PUT or POST is rather important for a
client to know.

LLSD can (of course) be used without LLIDL; most uses of LLSD today do not
use LLIDL (since it was invented later).


> I'd go further and suggest that binding to specific serializations is
> unnecessary coupling too.  While defining the three serializations is of
> course very useful, they should not be defined in the same document as
> LLIDL/LLSD, but in a separate set of parallel documents to which more
> serialization specs could be added later.
>

IMHO, splitting this one into multiple documents would produce unnecessary
clutter and overhead. The specification should not preclude other
serialization formats, and subsequent RFCs could be published that add
additional formats.

For example, Google's Protocol Buffers and Facebook's Thrift provide very
> popular and very efficient serializations which have raised much interest as
> alternatives to the legacy binary serialization of LLSD, as they are much
> more appropriate for use over TCP-based transports.  The LLIDL/.LLSD
> specification should not have to be revised when one or both of these new
> serializations are defined.  All it should require is to add a new document
> in parallel with a set of 3 documents that define the current 3
> serializations.
>

There should be nothing in the wording of the type systems I-D that
precludes new specs providing further serializations. If there is, please
point it out and it should be corrected.