Re: [ogpx] LLIDL, LLSD, Transport

[Morgaine <[e-mail]>]

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]> wrote:

>
> 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.
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>