Re: [vwrap] is the group still interested in LLSD or DSD?

Dzonatas Sol <dzonatas@gmail.com> Wed, 04 May 2011 18:06 UTC

Return-Path: <dzonatas@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 0DBF4E07C5 for <vwrap@ietfa.amsl.com>; Wed, 4 May 2011 11:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.917
X-Spam-Level:
X-Spam-Status: No, score=-3.917 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, 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 fyvTZ9TG6cxP for <vwrap@ietfa.amsl.com>; Wed, 4 May 2011 11:06:36 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30C75E07C9 for <vwrap@ietf.org>; Wed, 4 May 2011 11:06:36 -0700 (PDT)
Received: by pvh1 with SMTP id 1so785871pvh.31 for <vwrap@ietf.org>; Wed, 04 May 2011 11:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UwJbekgTuxEusl2/9rs3Ucb5M8NzYhr3mOFMM1dpum4=; b=RiWTkPyDHw++B/VQaF0jJIZta+giPaW6LoHXn3Oecr2ACSoTPmDMSOjvzjqWUGBc3g UODx+YHQGEZR+OYvxUBvvPEb/GFoTuAgSJ5vbZp1cb7ipiRqbPFOXbKXe0RvzVUJBfyX aLGXVZStmgxApbKESrlOkQx1O7YwLe9Rynxnw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=CdamkHYC9FqSjKdvjjgD0BLXl3Qr9Be3zflafZP/CB23jW1IDwJIwUWk8PMDGA/rnX 2cxEw3EjOi+F3WR8SSc2u19XV5sdc+iklFqM9ZBxAVqmX0ikZAXqrxEfEoStv+66XwUT IMZ+G8dXSxBquvjA8Frhh4ktY3pj8FrX3tz1c=
Received: by 10.68.36.232 with SMTP id t8mr1922254pbj.82.1304532395936; Wed, 04 May 2011 11:06:35 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id e4sm875571pbj.4.2011.05.04.11.06.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 11:06:35 -0700 (PDT)
Message-ID: <4DC1956A.5020204@gmail.com>
Date: Wed, 04 May 2011 11:05:30 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: vwrap@ietf.org
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>
In-Reply-To: <BANLkTi=hhsiDs=fdZRsthp_+5Hs+pR4L6A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [vwrap] 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: Wed, 04 May 2011 18:06:37 -0000

On 05/04/2011 10:22 AM, Morgaine wrote:
> Let me rephrase it more precisely.� Your responses do not 
> *demonstrate* understanding of the type model of LLSD + 
> serializations.� You persist in suggesting that the extensibility of 
> XML can extend the elementary types of LLSD, when it absolutely cannot 
> do that.� I am confident that you do understand this, but it hasn't 
> come across yet.
>
> I recommend leaving XML out of the discussion, because it's just one 
> out of 3 primary serializations.� Leaving it out (for now) will help 
> highlight the non-extensibility of the LLSD elementary data types.

XML is only a more graphic form than ASCII and extended with common 
multi-byte format useful to detect network order. Because it is 
human-readable, many miss *that* obvious critical fact. If you send XML 
data, we don't have to worry about the network order for whatever 
abstract data types you make up.

XML is more than just serialization and mark-up language, yet this how 
people *start* with such concepts. It remains very useful for more 
advanced flows with absolute simplicity to the core to parse, and 
continues to be ridiculously easy to optimize, tokenize, and compress 
(with static dictionaries). Note that with static dictionaries, concerns 
like power consumption are already thought about because to even get 
that analytic computation done for each and every message only consumes 
more power.

You're telling us you want to leave that already well-thought-critical 
details out of the discussion when it is already standardized and 
already just easily said as "XML"?

We realize that some implementers made LLSD mean "Linden Lab Serialized 
Data", and they wanted JSON instead because it *was* easily to eval() to 
parse. (Except now JSON has to avoid injections just like SQL & 
perl/php, etc, ...).

I'm pretty sure the real problem has been DEMONSTRATED with the 
implementation(s), especially where you further demonstrated that you 
want to leave out any mention of the extensibility features in order to 
show the problem with non-extensibility. That sounds familiar.


> It's a really fundamental aspect of the ADT that it defines our types 
> independent of its serializations. �It's a useful concept, but the 
> problem with this particular one -- LLSD (DSD?) -- is that the 
> elementary types are neither flexible nor extensible.
>

Let the VMs define further ADTs. We only need a few standard data types. 
This WG should only be concerned with being able to document (and 
clarify) the flow, especially the region-agent transistions. If the flow 
uses standard LLSD data types to define some complex abstract data type, 
perfect enough. I wouldn't be surprised if we add one more LLSD data 
type for DAEs, as that may be the perfect place for it. Then you can go 
and add any relevant extension you want to the DAE, even more abstract 
data types within the DAE, and further you don't even have to worry 
about it all being in RFC format.


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant