Re: [ogpx] LLIDL, LLSD, Transport
"Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com> Tue, 16 February 2010 17:29 UTC
Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837BE3A6818 for <ogpx@core3.amsl.com>; Tue, 16 Feb 2010 09:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.77
X-Spam-Level:
X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjrvQZjWnQZd for <ogpx@core3.amsl.com>; Tue, 16 Feb 2010 09:29:44 -0800 (PST)
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 5534128C0F5 for <ogpx@ietf.org>; Tue, 16 Feb 2010 09:29:43 -0800 (PST)
Received: by fxm7 with SMTP id 7so7458533fxm.28 for <ogpx@ietf.org>; Tue, 16 Feb 2010 09:31:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.239.185.212 with SMTP id d20mr674023hbh.178.1266341474224; Tue, 16 Feb 2010 09:31:14 -0800 (PST)
In-Reply-To: <3a880e2c1002160930m62331489v431e647b15b92612@mail.gmail.com>
References: <OF9C5B1597.47D03774-ON852576CB.006382E5-852576CB.006409C6@us.ibm.com> <4B79B2C9.8020800@cox.net> <3a880e2c1002151410q6b2b50a0ic8a527217fd4104b@mail.gmail.com> <3a880e2c1002151412y779cb377xb83f8cd0bab14fbb@mail.gmail.com> <f72742de1002151943g67ea7752rb03acbd40aca5ca6@mail.gmail.com> <3a880e2c1002160930m62331489v431e647b15b92612@mail.gmail.com>
From: "Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com>
Date: Tue, 16 Feb 2010 09:30:54 -0800
Message-ID: <3a880e2c1002160930l237683a7n1d932c29c281c9d0@mail.gmail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="001485f44f72bc49de047fbb1966"
Subject: Re: [ogpx] LLIDL, LLSD, Transport
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2010 17:29:46 -0000
whoops. meant to send this to the list.. On Tue, Feb 16, 2010 at 09:30, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> 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 <josh@lindenlab.com> 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) < >> infinity@lindenlab.com> wrote: >> >>> also... we've all been cc:'ing our messages to ogpx-bounces@ietf.org, >>> 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) < >>> infinity@lindenlab.com> 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 <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 >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >>> >> >
- [ogpx] LLIDL, LLSD, Transport David W Levine
- Re: [ogpx] LLIDL, LLSD, Transport Lawson English
- Re: [ogpx] LLIDL, LLSD, Transport Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] LLIDL, LLSD, Transport Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] LLIDL, LLSD, Transport Hurliman, John
- Re: [ogpx] LLIDL, LLSD, Transport Morgaine
- Re: [ogpx] LLIDL, LLSD, Transport Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] LLIDL, LLSD, Transport Joshua Bell
- Re: [ogpx] LLIDL, LLSD, Transport Morgaine
- Re: [ogpx] LLIDL, LLSD, Transport Hurliman, John