Re: [ogpx] LLIDL, LLSD, Transport

["Hurliman, John" <[e-mail]>]

As a side note, we are successfully using LLSD inside a thin TCP transport for communication between hosts as part of an internal project. Defining LLIDL and using LLSD serialization without going near HTTP is  easy to do, and even happens in the VWRAP specs. http://tools.ietf.org/html/draft-hamrick-vwrap-launch-00 defines LLIDL for LLSD that is meant to be transported in a web document. Whether that web document is retrieved through GET, POST, FTP, Gopher, etc. has no relevance.

John

From: [e-mail] [mailto:[e-mail]] On Behalf Of Morgaine
Sent: Wednesday, February 24, 2010 3:51 PM
To: ogpx
Subject: Re: [ogpx] LLIDL, LLSD, Transport

Joshua, being rather fond of decoupling as a software power tool, I tend to favour decoupling in documentation as well --- cross-references are generally better than static inclusion.

With regard to the use of GET, PUT and so on, it seems to me that which operations are supported is only relevant within the particular layer that performs these operations.  The only other place where this knowledge might perhaps be exposed is in a prior facilities negotiation phase, if any.

Within their layer, these operation of course invoke corresponding operations at the next layer, but those corresponding operations should not really know what invoked them otherwise you would never be able to replace HTTP with some other transport without modifying the next layer as well.

Be that as it may, if you think that this would be rather difficult then at the very least I would like to try to find a few additional words to add to the serializations section, in order to make it clear that further serializations are possible and would not be unexpected.

This is particularly important I feel in regard to the binary serialization of LLSD which could usefully be joined at a later date by a Protocol Buffer or Thrift serialization over TCP.  I would wish to make it clear that our document places no obstacles in the way of further serializations, in the sense that appearance of such new serializations would not be regarded as incompatibility with the LLSD specification.


Morgaine.




==================================
On Tue, Feb 23, 2010 at 4:58 PM, Joshua Bell <[e-mail]<mailto:[e-mail]>> wrote:

On Mon, Feb 15, 2010 at 2:35 PM, Morgaine <[e-mail]<mailto:[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.


_______________________________________________
ogpx mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ogpx