Re: [ogpx] LLIDL, LLSD, Transport
Morgaine <morgaine.dinova@googlemail.com> Mon, 15 February 2010 22:33 UTC
Return-Path: <morgaine.dinova@googlemail.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 CCD2028C0F3 for <ogpx@core3.amsl.com>; Mon, 15 Feb 2010 14:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 v83CZwdDvr2m for <ogpx@core3.amsl.com>; Mon, 15 Feb 2010 14:33:48 -0800 (PST)
Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 2E72E28C10B for <ogpx@ietf.org>; Mon, 15 Feb 2010 14:33:48 -0800 (PST)
Received: by ewy28 with SMTP id 28so820285ewy.28 for <ogpx@ietf.org>; Mon, 15 Feb 2010 14:35:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=PneAnMLvmF8OfzdMN8XlUrGmvpE95AUk/a66FW2TWxc=; b=HLxdGgYUTAlFxnJGUIyVaLMdd+lvXibw09tlAQ1TguK9o/VXF6rAEg6AHcNYiXnYu6 gF81ma+xSlrPAN6OSJTYj7DhxhAeyasIOAnbS18k5uuP+qoyJl4Y7DSim3n9L675wQpf +eZbJIoozwIuGMIE2Q+wi+sB0TnpVCi60GevI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=g032wKH0hccoOmeyj20POkfJIJGFPCHchF2bP2281Dk2HGFExhVtnpj6+FIIJ/oJvh 9GvsasghxY+syVLB1SQtQ5jciGLeyH+IbnfLp8h6B7SsrD52HOb01lT41JJRqdeWtDxj 7Ipn330QkMmHQSZtc1ng98oZviA6SSxQntA24=
MIME-Version: 1.0
Received: by 10.216.88.136 with SMTP id a8mr2082348wef.77.1266273315894; Mon, 15 Feb 2010 14:35:15 -0800 (PST)
In-Reply-To: <4B79B2C9.8020800@cox.net>
References: <OF9C5B1597.47D03774-ON852576CB.006382E5-852576CB.006409C6@us.ibm.com> <4B79B2C9.8020800@cox.net>
Date: Mon, 15 Feb 2010 22:35:15 +0000
Message-ID: <e0b04bba1002151435g15b9050qeec1bde4b7d7c998@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx <ogpx@ietf.org>
Content-Type: multipart/alternative; boundary="0016e6d64c232eb499047fab3b49"
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: Mon, 15 Feb 2010 22:33:49 -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. ======================================== On Mon, Feb 15, 2010 at 8:47 PM, 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] 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