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

[Morgaine <[e-mail]>]

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

> On 05/04/2011 09:06 AM, Morgaine wrote:
>
>> I gather that you don't understand the type model of LLSD + serializations
>> then.
>>
>
> That is rude for you to assume that, and also consider that I have an
> active implementation. Please, be more serious.
>


I apologize, I should not have implied that you lack understanding, my bad!

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.



>
> I know you have realized this much as you tried to promote Icesphere in the
> past, yet your political stance changes too often. Such talk doesn't belong
> on this list, you could have simply e-mail off list and asked what you don't
> understand about what I know. (was that you that sent me private email?
> nope, doesn't have "Morgaine" on the sender) On that note: I don't
> appreciate how you and others have treated me as the escapegoat! What do you
> expect? To send the inventor of XYZ language to school to certify that he
> knows XYZ language?
>
>
> I supported Icesphere and SNOW-375 because XML-based REST was useful in
LL-derived viewers, today.  VWRAP is a very different use case.  We need to
design VWRAP for the future, not merely to work with the current-day SL and
current-day Opensim.




> LLSD was specifically stated in source as the high-level like data types
> useful at low-level languages: low-level scalar data. Go ahead and assume
> LLSD means... you know... what the "reverse engineers" called it. Now that
> Mono has LLVM, and Attachment laid of Mono-employees, we can only assume
> they didn't want to look at the source of the LL version. Maybe its better
> hands now, and less need to re-standardize and re-implement the CIL
> libraries that Microsoft already distributes.
>
> It's helpful to read the source, yet due to much anxiety-induced fears of
> that alone your argument is endless and redundant to reinvent generics when
> that is already done.
>
>
>
I have no idea what any of that means.

>
>
>> Your answers simply don't address the non-extensibility and
>> non-flexibility of elementary types.  The XML tail cannot wag the ADT dog.
>>  The relationship is the other way around, it's the ADT that defines the
>> elementary types, which are transported in all serializations.
>>
>
> I have, you just avoid the demonstrated flow and source for some reason.
> ADTs still have to stream in ordinary ways to flow.
>
>
>
I don't know what you mean here.  It doesn't seem related to ADT types.


>
>> You keep referring to the flexibility of XML, but that is irrelevant to
>> the ADT.
>>
>
>
> You obviously want to avoid XML, despite the very implementation is based
> on plain text headers and XML data. I'm not even gonna ask why you avoid
> this over and over. Can you answer the question about region-agent
> transistion and if SLTP is viable, or do you want to continue to send any
> abstract data over clear text?
>
>
> No I do not want to avoid XML, quite the opposite.

XML is one of the 3 initial serializations of LLSD and it's perfectly fine
for that, and I expect XML to be used a lot over HTTP transport.  But you
cannot extend the elementary types of the ADT by extending your XML.  That's
the "XML tail wagging the ADT dog" to which I referred --- it doesn't work
that way.  If you want extensible and/or flexible elementary types, the ADT
has to be defined to allow them, because those get serialized in all 3 (or
more) serializations, not just in XML.

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.


Morgaine.