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

[Dzonatas Sol <[e-mail]>]

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