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

[Dzonatas Sol <[e-mail]>]

I've already confirmed the addition of the "stream buffer" data type 
idea and know the boundaries well enough that such mechanism 
incorporates the solution for several discussion that have occurred here 
and elsewhere.

That's where you would want to add your "ADT". The *the flow* needs to 
remain consistent, as much as possible, and continue to work in future 
design with other possible metadata.

The draft WIP explained LLSD clearly enough that to totally redefine 
that LLSD for absolute extensibility is only *against* the flow of 
*support* for anything like pre-defined types; further, to continue to 
break such WIP only causes re-implementation, re-negotiation, and 
re-standardization of already definitive work. Is your goal to break 
that work flow and cause people to rewrite protocol drivers based, 
constantly, on every extensive "designing for the future" data type?

I call your motion careless "loop". Even C/C++ programmers know the 
avoid the pointer that points to itself.

Abstract type system does not mean the data has to be absolutely 
extensive every possible moment. Maybe that is somewhat possible if you 
expect hardware to automatically transform metallic physicals based on 
every machine language instruction that needs to be extensive. We do 
look at this at every scale besides your "game loop".

I like quantum-jargon because that avoids such ludicrous 
ever-every-sense. We are not dumb despite what people think about our 
druggie lingo and organic morphisms, as this shows you've gone down deep 
with scalability.

What your after has already been invented as the "dynamic compiler" 
simply in those words, not ADT. Note: we already did work on dynamic 
compilers decades ago. Don't tell me I don't know the power of these, 
"type extensibility is obviously far more powerful than having a wide 
range of predefined types". I've already posted related work on these 
lists, maybe you didn't recognize the simplicity.

Morgaine, you're out of scope.

After you get someone to implement your blessed extensive abstract type 
system, then I bet you'll want something even more raw then that.

We been there and like to inspire. Please, stay positive.

Do you object to the addition of one more predefined data types, like 
the "stream buffer"? There already is something like <xsd> 
http://www.w3schools.com/schema/ . The element <stream> is already in 
use. We already have tags for the deep down scalable raw structures.

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?

It works in notecards already to <embed> inventory: 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Asset#notecard

On 05/04/2011 02:02 PM, Morgaine wrote:
> On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol <[e-mail] 
> <mailto:[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] 
> <mailto:[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]>
>         <mailto:[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]>
>         <mailto:[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]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/listinfo/vwrap
>
>
>
>         _______________________________________________
>         vwrap mailing list
>         [e-mail] <mailto:[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] <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