Re: [ogpx] LLIDL, LLSD, Transport

["Infinity Linden (Meadhbh Hamrick)" <[e-mail]>]

whoops. meant to send this to the list..

On Tue, Feb 16, 2010 at 09:30, Infinity Linden (Meadhbh Hamrick) <
[e-mail]> 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
>
> --
>   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
>         http://wiki.secondlife.com/wiki/User:Infinity_Linden
>
>
> On Mon, Feb 15, 2010 at 19:43, Joshua Bell <[e-mail]> 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) <
>> [e-mail]> wrote:
>>
>>> also... we've all been cc:'ing our messages to [e-mail],
>>> which is probably not what we want to do.
>>>
>>> -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 14:10, Infinity Linden (Meadhbh Hamrick) <
>>> [e-mail]> 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.
>>>>
>>>> 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 <[e-mail]>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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>>>
>>
>