Subject: [ogpx] LLIDL, LLSD, Transport

From: David W Levine <[email-masked]>
Date: Mon, 15 Feb 2010 13:12:38 -0500

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

---

From: Lawson English <[email-masked]>
Date: Mon, 15 Feb 2010 13:47:05 -0700

David W Levine wrote:
> _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

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

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Mon, 15 Feb 2010 14:10:21 -0800

hey sai.

yeah. this spec doesn't mention that explicitly, but the idea is that it
doesn't REQUIRE services and clients to be on separate hosts.

also, it's not about a specific technology for IPC, but about systems that
want to communicate over the internet. if you wanted to "speak" LLIDL
between two processes on the same host, there would be several options.

a. create a service on 127.0.0.1 and let loopback do it's magic.

b. open a named pipe (or whatever your OS's equivalent is) and speak HTTP
over it.

c. extend this spec with something more appropriate for IPC. maybe just
communicate between services and clients with a binary serialization across
a shared memory interface where request / response semantics are somehow
added in with the client library.

so there's plenty of options, but the important takeaway is that LLIDL is
supposed to define services that are accessed over HTTP over the internet.

-cheers
-meadhbh
--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Mon, Feb 15, 2010 at 12:47, Lawson English <[email-masked]> wrote:

> David W Levine wrote:
>
>>
>> I've taken a quick read over _
>> http://tools.ietf.org/html/draft-hamrick-vwrap-type-system-00_
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Mon, 15 Feb 2010 14:12:47 -0800

also... we've all been cc:'ing our messages to [email-masked], which
is probably not what we want to do.

-cheers
-meadhbh

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 15 Feb 2010 15:16:11 -0700

Since bi-directional HTTP has finally gone the way of the dinosaur and been replaced by WebSockets, it seems out of place to talk about LLSD as being exclusively for HTTP. Is there a reason the message format is necessarily bound to the transport mechanism, or can we drop the HTTP references?

John

On Feb 15, 2010, at 4:10 PM, "Infinity Linden (Meadhbh Hamrick)" <[email-masked]<mailto:[email-masked]>> wrote:

hey sai.

yeah. this spec doesn't mention that explicitly, but the idea is that it doesn't REQUIRE services and clients to be on separate hosts.

also, it's not about a specific technology for IPC, but about systems that want to communicate over the internet. if you wanted to "speak" LLIDL
between two processes on the same host, there would be several options.

b. open a named pipe (or whatever your OS's equivalent is) and speak HTTP over it.

c. extend this spec with something more appropriate for IPC. maybe just communicate between services and clients with a binary serialization across a shared memory interface where request / response semantics are somehow added in with the client library.

so there's plenty of options, but the important takeaway is that LLIDL is supposed to define services that are accessed over HTTP over the internet.

-cheers
-meadhbh
--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        <http://wiki.secondlife.com/wiki/User:Infinity_Linden> http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Mon, Feb 15, 2010 at 12:47, Lawson English <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
David W Levine wrote:

I've taken a quick read over _<http://tools.ietf.org/html/draft-hamrick-vwrap-type-system-00_>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
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/ogpx>https://www.ietf.org/mailman/listinfo/ogpx

---

From: Morgaine <[email-masked]>
Date: Mon, 15 Feb 2010 22:35:15 +0000

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.

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

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Tue, 16 Feb 2010 09:30:54 -0800

whoops. meant to send this to the list..

On Tue, Feb 16, 2010 at 09:30, Infinity Linden (Meadhbh Hamrick) <
[email-masked]> wrote:

> thx for the clarification josh.
>
> so now my question is... do we want to define LLIDL in a reverse direction?
>
> we define server -> client communication in terms of an event queue (in the
> foundation doc.) the current implementation uses a long poll. this will
> generally work, but several people have pointed out it's not without it's
> own weaknesses.
>
> in stockholm there was discussion of using LLIDL to define "events." in
> other words, adding grammar to LLIDL to allow the developer to specify the
> structure and composition of events that come over the event queue. (they're
> currently defined as "undef," meaning there's no way for a service developer
> to express (with LLIDL) the "shape" of an event. this is useful for logging,
> at least.)
>
> there was not inconsiderable discussion about "client side capabilities."
> (hint, hint zha... you're cue to remind us of your use case(s) with client
> side caps.)
>
> so now that we've pushed out a version of LLIDL / LLSD that represents a
> very small incremental over what's actually deployed right now. let's talk
> about some of these features..
>
> 1. do we want to use LLIDL to define the structure of server -> client
> messages?
>
> 2. do we want to add grammar to LLIDL (or some other specification layered
> on top of LLIDL) to define the structure of an event in an event queue.
>
> 3. do we want to support client side capabilities. these caps would have
> the characteristic that they would be a) routable and b) portable. in other
> words, they would probably be implemented as a URL on a server with a public
> IP address, but would represent a resource on a client. "portable" means
> that they're really caps... that is, you could give one to a remote 3rd
> party and they could use them as easily as the machine/process that
> requested them.
>
> 4. do we want to revisit using BWTP as a transport? some of us like it's
> characteristics. or should we ONLY worry about WebSockets (*shudder*).
>
> 5. is there anyone with an interest in layering VWRAP messages over XMPP
> (or BEEP, or IIOP, or ... ) who would be willing to write a draft describing
> it's use and definition?
>
> -cheers
> -meadhbh
>
> --
> On Mon, Feb 15, 2010 at 19:43, Joshua Bell <[email-masked]> wrote:
>
>> I think this is the point in the thread where we want to say: "We have
>> implementation experience with HTTP. If anyone else can provide
>> implementation experiences with other transports, please step in now and
>> suggest concrete modifications to the spec."
>>
>> I can follow up pointing out that there's no reason we need to include
>> those now; we can issue a revised RFC later that adds new LLIDL productions
>> for non-RESTful scenarios.
>>
>>
>> On Mon, Feb 15, 2010 at 5:12 PM, Infinity Linden (Meadhbh Hamrick) <
>>> also... we've all been cc:'ing our messages to [email-masked],
>>> which is probably not what we want to do.
>>>
>>> -cheers
>>> -meadhbh
>>> --
>>>> also, it's not about a specific technology for IPC, but about systems
>>>> that want to communicate over the internet. if you wanted to "speak" LLIDL
>>>> so there's plenty of options, but the important takeaway is that LLIDL
>>>> is supposed to define services that are accessed over HTTP over the
>>>> internet.
>>>>
>>>> -cheers
>>>> -meadhbh
>>>> --
>>>> On Mon, Feb 15, 2010 at 12:47, Lawson English <[email-masked]>wrote:
>>>>
>>>>> David W Levine wrote:
>>>>>
>>>>>>

---

From: Joshua Bell <[email-masked]>
Date: Tue, 23 Feb 2010 08:58:39 -0800

> without requiring change to the specification document of the layer above

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

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

> in parallel with a set of 3 documents that define the current 3

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.

---

From: Morgaine <[email-masked]>
Date: Wed, 24 Feb 2010 23:50:36 +0000

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 <[email-masked]> wrote:

> * 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)
>

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 24 Feb 2010 18:56:11 -0700

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: [email-masked] [mailto:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Feb 15, 2010 at 2:35 PM, Morgaine <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ogpx