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

[Morgaine <[e-mail]>]

On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol <[e-mail]> wrote:

> I would like to add the "stream buffer" data type, with optional metadata
> to normalize access to higher-levels, and with intent of content
> extraction/replacement by element tag (like XPath). This would make it so
> much easier to implement asset servers and agent services. (Yet, I rather
> have more implementation first than simple Schroedinger's cat idealogy to
> base RFC submission).
>
> Do you want to update the text below to add your "ADT" to the already
> implemented type system?



???

Although I don't actually understand what you've written above, or why, I'm
going to try to help by taking a wild guess at what you might have meant.
It's possible that you believe that I have some concrete types in mind that
I want to add to LLSD's predefined set of primitive types, and that you are
inviting me to add them.  Is that the right interpretation?

Assuming that this is so, please note that whatever types I may have in
mind, adding them to the predefined set of LLSD will not make that set of
types extensible.  All it will achieve is to make LLSD more flexible *for me
*, by adding types that I happen to want.  Adding more predefined primitive
types does add flexibility, but flexibility and extensibility are two
different things.

Type extensibility is obviously far more powerful than having a wide range
of predefined types, because it would allow you to extend the set of
primitive types in the ADT however you wish, so the future is open-ended.
Despite that, it is quite common to aim for a flexible set of primitive
types instead of an extensible one.  We could aim for a more flexible set of
primitive types for VWRAP, or we could aim for an extensible set, or a bit
of both.  But to provide neither is a very poor choice, and would not be
"designing for the future".

If we were to choose flexibility instead of extensibility for our ADT
system, I would certainly recommend very strongly that all the usual integer
types be predefined, because they are used extremely widely, and provide for
very efficient binary serializations.  That would be a good start!

Before we continue this line of discussion further though, perhaps you'd
better confirm that this is the topic that you had in mind above, because
your mention of "stream buffer data type with optional metadata" makes me
think that there is a strong chance that you're referring to something
completely different.


Morgaine.





======================

On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol <[e-mail]> wrote:

> I would like to add the "stream buffer" data type, with optional metadata
> to normalize access to higher-levels, and with intent of content
> extraction/replacement by element tag (like XPath). This would make it so
> much easier to implement asset servers and agent services. (Yet, I rather
> have more implementation first than simple Schroedinger's cat idealogy to
> base RFC submission).
>
> Do you want to update the text below to add your "ADT" to the already
> implemented type system?
>
> In WIP: http://tools.ietf.org/html/draft-ietf-vwrap-type-system-00
> Section 2:
>
>   The LLSD abstract type system describes the semantics of data passed
>   between two network hosts.  These types characterize the data when
>   serialized for transport, when stored in memory, and when accessed by
>   applications.
>
>   The types are designed to be common enough that native types in
>   existing serializations and programming languages will be usable
>   directly.  It is anticipated that LLSD data may be serialized in
>   systems with fewer types or stored in native programming language
>   structures with less precise types, and still interoperate in a
>   predictable, reliable manner.  To support this, conversions are
>   defined to govern how data received or stored as one type may be read
>   as another.
>
>   For example, if an application expects to read an LLSD value as an
>   Integer, but the serialization used to transport the value only
>   supported Reals, then a conversion governs how the application will
>   see the transported value.  Another case would be where an
>   application wants to read an LLSD value as a URL, but the programing
>   language only supports String as a data type.  Again, there is a
>   defined conversion for this case.
>
>   The intention is that applications will interact with LLSD data via
>   interfaces in terms of these types, even if the underlying language
>   or transports do not directly support them, while retaining as much
>   direct compatibility with those native types as possible.
>
>   An LLSD value is either a simple datum or a composite structure.  A
>   simple data value can have one of nine simple types: Undefined,
>   Boolean, Integer, Real, String, UUID, Date, URI or Binary.  Composite
>   structures can be either of the types Array or Map.
>
>
>
> On 05/04/2011 11:26 AM, Morgaine wrote:
>
>> On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <[e-mail] <mailto:
>> [e-mail]>> wrote:
>>
>>
>>    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.
>>
>>
>> This is what I can't seem to get across to you.  All those wonderful
>> features of XML are *IRRELEVANT* to the extensibility of the ADT's primitive
>> types, because the ADT defines its very limited set of abstract types
>> itself, directly.  The only thing that the ADT's serializations can do is
>> express those predefined ADT types on the wire.  You can't extend the
>> primitive types in a serialization of the ADT.
>>
>> If you were arguing that our ADT's primary type definitions should be in
>> XML then you would have quite a good point, because then the types would be
>> both flexible and extensible.  But that's not what we're discussing here.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> ==========================
>>
>> On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <[e-mail] <mailto:
>> [e-mail]>> wrote:
>>
>>    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
>>
>>    _______________________________________________
>>    vwrap mailing list
>>    [e-mail] <mailto:[e-mail]>
>>    https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>