Re: [vwrap] The <embed> tag... is the group still interested in LLSD or DSD?

Vaughn Deluca <vaughn.deluca@gmail.com> Thu, 05 May 2011 06:32 UTC

Return-Path: <vaughn.deluca@gmail.com>
X-Original-To: vwrap@ietfa.amsl.com
Delivered-To: vwrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A92E06DD for <vwrap@ietfa.amsl.com>; Wed, 4 May 2011 23:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id natzFgMiR+ot for <vwrap@ietfa.amsl.com>; Wed, 4 May 2011 23:32:08 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC02E06C0 for <vwrap@ietf.org>; Wed, 4 May 2011 23:32:08 -0700 (PDT)
Received: by eye13 with SMTP id 13so652382eye.31 for <vwrap@ietf.org>; Wed, 04 May 2011 23:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gAf8n4fl8tPrN/WOKQhNHHppPR37pO//vJ0OqYCKwxI=; b=ixRvi7L07/zoKZA5KopeClDyFhqdi7FmAPsphl3DJR6e/lySCfPwt9iBauF+cqpb2z mdIRCeWUOW4q/jcWgzmlcMYkO93zofekC0UGlOziGbNme9OBtRMDzvhqjW4Fl0qWC9Fq T/XSYo5rxT73/IH0ip2BUKsSH6NfyTN2uj3KY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mHNTNvgWi+Y/P2f7Mwz1SOznq+bqQC3QRt/2TV/4tz2bYKSxcawmI3D4L+k2fqcsXr bQ10a9+fBW/eVgygRYn4KFhiuH/NOzlKCGdjrP6gWlK8Ji2V2qd31VTQwCeOsuAZ2ybr wHzE7BabMqSnZiA6oQgqN+9wMJC7AVSsEaXdU=
MIME-Version: 1.0
Received: by 10.213.26.155 with SMTP id e27mr50549ebc.136.1304577127195; Wed, 04 May 2011 23:32:07 -0700 (PDT)
Received: by 10.213.30.6 with HTTP; Wed, 4 May 2011 23:32:07 -0700 (PDT)
In-Reply-To: <BANLkTik81Eht3NTdLXXmgqOWvjc2s_KBnw@mail.gmail.com>
References: <BANLkTi=g9T5q5bVgytpxRxuE=Oc9iG2F9w@mail.gmail.com> <BANLkTi=K8-6oL-JJoPCfz0JjDpaRBpeOyg@mail.gmail.com> <4DC15504.3090503@gmail.com> <BANLkTikay4xhQoZs2L0uRLSXgUMfCE9yfA@mail.gmail.com> <4DC160F0.1030201@gmail.com> <BANLkTikTYpLHM=GAeGAVfufqZ5XT0FSAzw@mail.gmail.com> <BANLkTi=kjBSuMjPcgfXTUvZ3iwmS1bN50Q@mail.gmail.com> <4DC17704.3020201@gmail.com> <BANLkTimpGpNrkE3WUdurduqrVumocDRwfQ@mail.gmail.com> <4DC1824B.6040609@gmail.com> <BANLkTi=hhsiDs=fdZRsthp_+5Hs+pR4L6A@mail.gmail.com> <4DC1956A.5020204@gmail.com> <BANLkTik8rnsKP4xq+Gj5G4dsG=UOVnkNSQ@mail.gmail.com> <4DC1A8C9.9090406@gmail.com> <BANLkTikkOS34CC+ML0JNJgHDoRqbs9rY9w@mail.gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <BANLkTik81Eht3NTdLXXmgqOWvjc2s_KBnw@mail.gmail.com>
Date: Thu, 5 May 2011 08:32:07 +0200
Message-ID: <BANLkTi=-heHa35w43te0ba8NufkT+MP+CQ@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: multipart/alternative; boundary=0015174c138e3fa3f804a2818818
Cc: vwrap@ietf.org
Subject: Re: [vwrap] The <embed> tag... is the group still interested in LLSD or DSD?
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2011 06:32:09 -0000

Morgaine,

You observe LLSD is not extendable. Dzonatas argues that the this can be
solved at a higher level using XML.  You object that this  entangles the
serialisation with basic ADT

So what do you suggest is the way forward?
- Can LLSD itself be made extensible?
-if not, do we have enough commitment in the group to start from scratch?
-if not, do the benefits of an absolutely clean engineering solution
outweighs the costs of disrupting the already slow progress here? We reach
for the sky, but run the risk of over extending our current capabilities.

I am all for rigorous design, but i think i prefer actual implementation of
an imperfect system over sitting and waiting for an ultimate dream.
If we don't get demonstrated commitment for specifying (and implementing!)
an alternative, my vote go's to sticking with LLSD, if only to show
conclusively were it falls short of our needs.

-- Vaughn


On Thu, May 5, 2011 at 12:59 AM, Morgaine <morgaine.dinova@googlemail.com>wrote;wrote:

> I have no idea what either of the last list two posts meant.
>
> I tried to interpret the preceding post as best I could and to find room
> for technical discussion, but clearly the attempt has failed.
>
> I'll leave it at that.
>
>
> Morgaine.
>
>
>
> ===========================
>
>
>
> On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
>
>> On 05/04/2011 03:21 PM, Dzonatas Sol wrote:
>>
>>> Actually, I invented one tag called <embed> that does all the above
>>> already, so how about the predefined embed'ed data type instead of endless
>>> extensibility?
>>>
>>>
>> On that NOTE: any more needed extensibility is transistioned into
>> capabilities.
>>
>> Whereas, capabilities means more resources (as dynamic extensions grow);
>> therefore, this requires minimization of number of connections instead of
>> one connection per resource. Thus, that proportion leads into the reason for
>> combined/bundled queries that I have already mentioned and implemented, as
>> maximum # of connections are too easily reached without such mechanism.
>>
>>
>> --
>> --- https://twitter.com/Dzonatas_Sol ---
>> Web Development, Software Engineering, Virtual Reality, Consultant
>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>