Re: [ogpx] LLIDL, LLSD, Transport

Good points from David and Lawson.  Both hint at something that's been
worrying me, namely inappropriate bundling of specifications at different
layers of the stack.

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'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.

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.

A specification should wherever possible stick to one layer of the stack.
This makes the spec cohesive and tightly defined without leaking into any
other layer, and provides the greatest amount of flexibility for
implementers and document writers alike.

Morgaine.

========================================

On Mon, Feb 15, 2010 at 8:47 PM, Lawson English <lenglish5@cox.net> wrote:

> David W Levine wrote:
>
>>
>> I've taken a quick read over _
>> http://tools.ietf.org/html/draft-hamrick-vwrap-type-system-00_
>> and unless I'm misreading the draft, it binds exclusively onto http(s) as
>> transport. Given  all the
>> work in hybi and websocket in adjacent working groups in the applications
>> area of IETF, this
>> seems... problematic  Comments?
>>
>> - David
>> ~ Zha
>>
>
> Not to mention client services that are hosted on localhost might be using
> tcp or shared memory for extra speed (ala the SL media plugin).
>
>
> Lawson
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>