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

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 3 May 2011 07:19:55 -0700

is anyone in this group still interested in using LLSD (or it's successor, DSD)?

if so, i'm going to publish the DSD draft here. if not, i'm going to
wait for the group to say "we are in no way interested in LLSD or DSD"
and then submit it as an individual submission to the RFC editor. it's
been about three years, and i would really like to get an RFC
published so i can take the X- off all my application/llsd family of
mime types.

so... may i see a show of hands... is anyone still planning on
implementing a system with LLSD in this group?

please just respond yes or no in reply to this thread. i'll start
another thread for discussion.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 13:24:57 +0100

You're mixing up two very different questions, Meadhbh:  the first is
whether anyone is going to use DSD for something personally (in the way that
they have already used LLSD in the past), and the second is whether VWRAP
might adopt DSD for its type system.

The answer to the first is clearly "*Yes*" because it's already been done
with LLSD in an ad hoc fashion.  However, it would be excellent if you were
to publish a proper RFC on DSD, and even better if you could provide an
actual library and bindings/API for it.  None of the current implementations
of LLSD went as far as creating separate and directly usable LLSD API
projects maintained by their creators, as the libomv and C++ implementations
are entangled within the very large codebases of their respective projects,
and the other implementations are poor quality and not maintained.  You
could do much better than they did, and keep a discrete DSD library afloat
and up to date.  That would ensure its survival.

The answer to the second question is equally clearly "*No*", because IETF
working groups don't work through proposers' ultimatums.  A few weeks ago
there were significant questions raised here about whether LLSD/DSD is
adequate for a standard that is intended *for the future* of VWs rather than
for implementing today's SL and Opensim-based software, so it's clear that
the issue hasn't been decided and requires more examination.

Carlo put it (rather bluntly) here ---
http://www.ietf.org/mail-archive/web/vwrap/current/msg00569.html .  Without
going into the politics of it, I want to see VWRAP have a properly
extensible type system, and the current LLSD does not meet that
requirement.  Indeed, in the early days of our IETF effort, we spent months
discussing the width of integers in LLSD because there was only *one
width*allowed and it was
*hardwired* in the spec.  That's not an extensible approach to data types at
all.

We need to do a lot better in this area if we really mean "extensible" when
we say "extensible".  At present that ADT proposal is not extensible in any
meaningful way.

Morgaine.

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

On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick <[email-masked]> wrote:

> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 06:30:44 -0700

I considered LLSD format not just for legacy reasons, yet LL obviously 
used it because it is easier to document. It can be improved, yes, so I 
don't see the argument about it's extensibility of any merit. If the 
data can be traslated to XML, then we know we can further translate into 
other types or formats that work better. Usually that 'better' is 
something considered 'obvious' with RFCs, and that's where we 
'obviously' don't have to update the RFC.

There is enough reason to update the RFC for combined queries (and 
further denote such in LLIDL for pivotal data), yet seems like people 
have gone other routes, like SPDY, to accomplish the same basis in 
connection pipelines. I think the IDL needs to be in as format that 
others WGs besides VWRAP can use, and to denote the pivotal data only 
focuses more on the region-agent transistions. Realize that we are not 
all on the same scale as we work this, which is normal.

I don't see why to update the RFC if it doesn't at least address that. 
Otherwise, I'm not against either LLSD or DSD. I do prefer the symbolic 
assembly equivalent before the plain english equivalent The symbolic 
equivalent tends to avoid use of reserved words in LLIDL.

I think the extensibility of LLSD is moot given the XML translation is 
given. Anybody can further extend the XML data. For example, here is 
JSONx: https://datatracker.ietf.org/doc/draft-rsalz-jsonx . So, from XML 
to XML of those documents two are now trivial WIP.

On 05/04/2011 05:24 AM, Morgaine wrote:
> You're mixing up two very different questions, Meadhbh:� the first is 
> whether anyone is going to use DSD for something personally (in the 
> way that they have already used LLSD in the past), and the second is 
> whether VWRAP might adopt DSD for its type system.
>
> The answer to the first is clearly "*Yes*" because it's already been 
> done with LLSD in an ad hoc fashion.� However, it would be excellent 
> if you were to publish a proper RFC on DSD, and even better if you 
> could provide an actual library and bindings/API for it.� None of the 
> current implementations of LLSD went as far as creating separate and 
> directly usable LLSD API projects maintained by their creators, as the 
> libomv and C++ implementations are entangled within the very large 
> codebases of their respective projects, and the other implementations 
> are poor quality and not maintained.� You could do much better than 
> they did, and keep a discrete DSD library afloat and up to date.� That 
> would ensure its survival.
>
> The answer to the second question is equally clearly "*No*", because 
> IETF working groups don't work through proposers' ultimatums.� A few 
> weeks ago there were significant questions raised here about whether 
> LLSD/DSD is adequate for a standard that is intended /for the future/ 
> of VWs rather than for implementing today's SL and Opensim-based 
> software, so it's clear that the issue hasn't been decided and 
> requires more examination.
>
> http://www.ietf.org/mail-archive/web/vwrap/current/msg00569.html .� 
> Without going into the politics of it, I want to see VWRAP have a 
> properly extensible type system, and the current LLSD does not meet 
> that requirement.� Indeed, in the early days of our IETF effort, we 
> spent months discussing the width of integers in LLSD because there 
> was only *one width* allowed and it was *hardwired* in the spec.� 
> That's not an extensible approach to data types at all.
>
> We need to do a lot better in this area if we really mean "extensible" 
> when we say "extensible".� At present that ADT proposal is not 
> extensible in any meaningful way.
>
>
> Morgaine.
>
>
>
> ====================
>
> On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

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

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 15:02:34 +0100

Extensibility through XML is not extensibility of the types of the
underlying ADT.

The types of the ADT are expressed through 3 canonical serializations.
Those serializations merely reflect the types defined by the underlying ADT,
and the XML serialization alone cannot extend the underlying ADT without
breaking the mapping of the ADT to the other serializations.

It's the type system itself that has to be extensible before you can validly
use extended types in one of its serializations.

Morgaine.

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

On Wed, May 4, 2011 at 2:30 PM, Dzonatas Sol <[email-masked]> wrote:

> I considered LLSD format not just for legacy reasons, yet LL obviously used
> it because it is easier to document. It can be improved, yes, so I don't see
> the argument about it's extensibility of any merit. If the data can be
> traslated to XML, then we know we can further translate into other types or
> formats that work better. Usually that 'better' is something considered
> 'obvious' with RFCs, and that's where we 'obviously' don't have to update
> the RFC.
>
> There is enough reason to update the RFC for combined queries (and further
> denote such in LLIDL for pivotal data), yet seems like people have gone
> other routes, like SPDY, to accomplish the same basis in connection
> pipelines. I think the IDL needs to be in as format that others WGs besides
> VWRAP can use, and to denote the pivotal data only focuses more on the
> region-agent transistions. Realize that we are not all on the same scale as
> we work this, which is normal.
>
> given. Anybody can further extend the XML data. For example, here is JSONx:
> https://datatracker.ietf.org/doc/draft-rsalz-jsonx . So, from XML to XML
> of those documents two are now trivial WIP.
>
>
>> with LLSD in an ad hoc fashion.� However, it would be excellent if you were
>> actual library and bindings/API for it.� None of the current implementations
>> and the other implementations are poor quality and not maintained.� You
>> and up to date.� That would ensure its survival.
>>
>> working groups don't work through proposers' ultimatums.� A few weeks ago
>> adequate for a standard that is intended /for the future/ of VWs rather than
>> Without going into the politics of it, I want to see VWRAP have a properly
>> requirement.� Indeed, in the early days of our IETF effort, we spent months
>> discussing the width of integers in LLSD because there was only *one width*
>> allowed and it was *hardwired* in the spec.� That's not an extensible
>> approach to data types at all.
>>
>> when we say "extensible".� At present that ADT proposal is not extensible in
>> any meaningful way.
>>
>>
>> Morgaine.
>>
>>
>>
>> ====================
>>
>> On Tue, May 3, 2011 at 3:19 PM, Meadhbh Hamrick <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 07:21:36 -0700

We already know highly abstract data types that have all kinds of 
extensibility, so there is no need to reinvent that much.

We just need "best fit" for the documentation and basic usage of 
resources as capabilities with LLIDL.

Any further extensibility is specific to implementation, and that 
specific implementation should be expected (as common mode with RFCs). 
What matters is, can we use these data types to convey the concept? Yes, 
we have demonstrated we can.

Again, I worry less about that and more about the combine queries, which 
would let you extend in many other ways besides mere serialization, 
especially when pivotal data is known.

Your argument only justifies further reason for me to move and update 
SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 ) 
to the IETF wiki, especially if we expect STLP, which I rather 
forward-think about, instead of private unencrypted URIs.

On 05/04/2011 07:02 AM, Morgaine wrote:
> The types of the ADT are expressed through 3 canonical 
> serializations.  Those serializations merely reflect the types defined 
> by the underlying ADT, and the XML serialization alone cannot extend 
> the underlying ADT without breaking the mapping of the ADT to the 
> other serializations.
>
> It's the type system itself that has to be extensible before you can 
> validly use extended types in one of its serializations.
>
>
> Morgaine.
>

--

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 4 May 2011 07:32:32 -0700

but the question was... yes or no... do we want LLSD or DSD (it's
successor) to be part of VWRAP moving forward?

On Wed, May 4, 2011 at 7:21 AM, Dzonatas Sol <[email-masked]> wrote:
> We just need "best fit" for the documentation and basic usage of resources
> as capabilities with LLIDL.
>
> Any further extensibility is specific to implementation, and that specific
> implementation should be expected (as common mode with RFCs). What matters
> is, can we use these data types to convey the concept? Yes, we have
> demonstrated we can.
>
> SNOW-375 ( http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375 ) to
> the IETF wiki, especially if we expect STLP, which I rather forward-think
> about, instead of private unencrypted URIs.
>
>
>>  Those serializations merely reflect the types defined by the underlying
>> ADT, and the XML serialization alone cannot extend the underlying ADT
>> without breaking the mapping of the ADT to the other serializations.
>>

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 08:08:55 -0700

Don't worry, I (we) "get it".

In attempts (to implement and) go forward with both LLSD and DSD, I 
already answered that question. I await your further effort to the 
effort I did to review your previous posts about DSD.

http://www.ietf.org/mail-archive/web/vwrap/current/msg00833.html

http://www.ietf.org/mail-archive/web/vwrap/current/msg00830.html

If you expect yours to remain "out of scope" to this WG, then lets 
continue to go forward with LLSD as-is.

Why use such straw-man to avoid the obvious concern of private 
unencrypted URIs, which breaks this WG if we continue to avoid this big 
elephant in the room. With the LLIDL additions I made for combined 
queries, this at least helps "secure" that insecurity with being able 
pipeline requests over pivotal data. Obviously, any demand to use only 
plain old HTTP leads right back to the elephant.

RFCs shouldn't be used to make people look stupid by default expected 
implementation. I hope no one here is trying to do this, yet the 
avoidance of this issue make this much questionable. There is an obvious 
level of concern about privacy and copybots. This elephant is a 
show-stopper unless you got lawyers already to help protect "the game". 
http://en.wikipedia.org/wiki/The_Game_%28mind_game%29

We're being more serious about simulation and region-agent transistion 
then just games (and its loops) that has been repeated for the last few 
years. The game needs to stop we are trying to address the issue.

Do recognize TLS/STLP as viable or do you continue to recommend to only 
send either LLSD or DSD over simple HTTP?

On 05/04/2011 07:32 AM, Meadhbh Hamrick wrote:
> On Wed, May 4, 2011 at 7:21 AM, Dzonatas Sol<[email-masked]>  wrote:
>    
>>> �Those serializations merely reflect the types defined by the underlying

--

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 16:49:42 +0100

That's a far clearer question than you asked initially, and so its easier to
give a specific answer.  (Indeed, I already did before, in the second part
of my response.)

While I don't know exactly what DSD is (an RFC would be excellent!), if it's
just LLSD with another name then the type system of its underlying ADT is
not extensible, and therefore it won't support new types going forward into
the future.  From my perspective, a non-extensible type system is *not
sufficient* for VWRAP because it blocks the evolution of transported
elementary types.

And LLSD is actually worse than merely non-extensible, because it isn't
flexible either, especially in providing just a single integer type.  That's
not enough.

We need to design for tomorrow, not just for today.

Morgaine.

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

On Wed, May 4, 2011 at 3:32 PM, Meadhbh Hamrick <[email-masked]> wrote:

> specific
> to

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 08:55:48 -0700

It doesn't block "evolution of transported elementary types", as the 
transport layer is underneath the application layer. As demonstrated 
(and proven) with flow in XML, we can easily keep the high-level types 
in the higher layer. LLSD is merely the high-level types, not overall 
primitives.

On 05/04/2011 08:49 AM, Morgaine wrote:
> That's a far clearer question than you asked initially, and so its 
> easier to give a specific answer.� (Indeed, I already did before, in 
> the second part of my response.)
>
> While I don't know exactly what DSD is (an RFC would be excellent!), 
> if it's just LLSD with another name then the type system of its 
> underlying ADT is not extensible, and therefore it won't support new 
> types going forward into the future.� From my perspective, a 
> non-extensible type system is *not sufficient* for VWRAP because it 
> blocks the evolution of transported elementary types.
>
> And LLSD is actually worse than merely non-extensible, because it 
> isn't flexible either, especially in providing just a single integer 
> type.� That's not enough.
>

--

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 17:06:36 +0100

I gather that you don't understand the type model of LLSD + serializations
then.

The ADT defines the elementary data types and composite resource types.  The
serializations then implement both of these for transport on-the-wire.
There is nothing that one specific serialization like XML can do to to
extend the elementary data types provided by the ADT.

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.

You keep referring to the flexibility of XML, but that is irrelevant to the
ADT.

Morgaine.

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

On Wed, May 4, 2011 at 4:55 PM, Dzonatas Sol <[email-masked]> wrote:

> transport layer is underneath the application layer. As demonstrated (and
> proven) with flow in XML, we can easily keep the high-level types in the
> higher layer. LLSD is merely the high-level types, not overall primitives.
>
>
>> That's a far clearer question than you asked initially, and so its easier
>> to give a specific answer.� (Indeed, I already did before, in the second
>> part of my response.)
>>
>> While I don't know exactly what DSD is (an RFC would be excellent!), if
>> it's just LLSD with another name then the type system of its underlying ADT
>> is not extensible, and therefore it won't support new types going forward
>> into the future.� From my perspective, a non-extensible type system is *not
>> flexible either, especially in providing just a single integer type.� That's
>> not enough.
>>

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 09:43:55 -0700

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 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?

>
> The ADT defines the elementary data types and composite resource 
> types.  The serializations then implement both of these for transport 
> on-the-wire.  There is nothing that one specific serialization like 
> XML can do to to extend the elementary data types provided by the ADT.

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.

>
> 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.

>
> 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?

--

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 18:22:50 +0100

> 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.

> 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.

>> 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 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.

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 11:05:30 -0700

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.

> 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.

--

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 19:26:30 +0100

On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <[email-masked]> wrote:

> 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 <[email-masked]> wrote:

>> Let me rephrase it more precisely.� Your responses do not *demonstrate*
>> understanding of the type model of LLSD + serializations.� You persist in
>> LLSD, when it absolutely cannot do that.� I am confident that you do
>> 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.
>>
>
> data, we don't have to worry about the network order for whatever abstract
> data types you make up.
>
> 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.
>
> details out of the discussion when it is already standardized and already
> just easily said as "XML"?
>
> parse. (Except now JSON has to avoid injections just like SQL & perl/php,
> etc, ...).
>
> 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.
>
>
>
>> independent of its serializations. �It's a useful concept, but the problem
> 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.
>
>
>
> --

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 12:28:09 -0700

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 <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         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
>         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, ...).
>
>     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.
>
>
>
>     -- 

--

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 22:02:27 +0100

On Wed, May 4, 2011 at 8:28 PM, Dzonatas Sol <[email-masked]> 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).
>

???

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 <[email-masked]> 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).
>
>> On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>
>> 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 <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>    --     --- https://twitter.com/Dzonatas_Sol ---

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 15:21:25 -0700

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 <[email-masked] 
>     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".
>
> 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 <[email-masked] 
>     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?
>
>         On Wed, May 4, 2011 at 7:05 PM, Dzonatas Sol
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>         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
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 15:41:00 -0700

> already, so how about the predefined embed'ed data type instead of 

On that NOTE: any more needed extensibility is transistioned into 
capabilities.

Whereas, capabilities means more resources (as dynamic extensions grow); 
therefore, this requires minimization of number of connections instead 
of one connection per resource. Thus, that proportion leads into the 
reason for combined/bundled queries that I have already mentioned and 
implemented, as maximum # of connections are too easily reached without 
such mechanism.

--

---

From: Morgaine <[email-masked]>
Date: Wed, 4 May 2011 23:59:10 +0100

I have no idea what either of the last list two posts meant.

I tried to interpret the preceding post as best I could and to find room for
technical discussion, but clearly the attempt has failed.

I'll leave it at that.

Morgaine.

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

On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol <[email-masked]> wrote:

>> already, so how about the predefined embed'ed data type instead of endless
>> extensibility?
>>
>>
> therefore, this requires minimization of number of connections instead of
> one connection per resource. Thus, that proportion leads into the reason for
> combined/bundled queries that I have already mentioned and implemented, as
> maximum # of connections are too easily reached without such mechanism.
>
>
> --

---

From: Vaughn Deluca <[email-masked]>
Date: Thu, 5 May 2011 08:32:07 +0200

Morgaine,

You observe LLSD is not extendable. Dzonatas argues that the this can be
solved at a higher level using XML.  You object that this  entangles the
serialisation with basic ADT

So what do you suggest is the way forward?
- Can LLSD itself be made extensible?
-if not, do we have enough commitment in the group to start from scratch?
-if not, do the benefits of an absolutely clean engineering solution
outweighs the costs of disrupting the already slow progress here? We reach
for the sky, but run the risk of over extending our current capabilities.

I am all for rigorous design, but i think i prefer actual implementation of
an imperfect system over sitting and waiting for an ultimate dream.
If we don't get demonstrated commitment for specifying (and implementing!)
an alternative, my vote go's to sticking with LLSD, if only to show
conclusively were it falls short of our needs.

-- Vaughn

On Thu, May 5, 2011 at 12:59 AM, Morgaine <[email-masked]>wrote:

> I tried to interpret the preceding post as best I could and to find room
> for technical discussion, but clearly the attempt has failed.
>
> I'll leave it at that.
>
>
> Morgaine.
>
>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 5 May 2011 15:33:21 +0100

> So what do you suggest is the way forward?

I suggest the following as a way forward with very little pain or delay:

   - As other serialization systems have done, add those predefined types
   that we can easily foresee will be very beneficial to VW applications.  That
   certainly includes all the usual integer types, maybe others.  We could
   agree on a useful set of them today, it's not hard.  It wouldn't be perfect,
   but it would be "our best shot" at supporting what the immediate future
   requires.  It would give our types system added *flexibility*, and its
   extra *efficiency* would improve the performance of our binary
   serializations.

   - As Carlo has suggested in the past, add a version negotiation system so
   that when VW projects find our 2011 set of base types inadequate, they can
   evolve the types system and negotiate use of a newer one dynamically at
   protocol initiation time, without needing to come back to the IETF.  This
   would give us a measure of *extensibility* without needing to make our
   initial elementary types extensible.

It can be made extensible, yes, but with this group's track record of
continually saying "No" even to simple technical advances, I would not want
to be an advocate for more complex extensible base types.  Instead, I'll
make do with Carlo's approach, ie. extensibility through negotiating
alternative versions.

> conclusively were it falls short of our needs.
Which is why I suggest that we do no more than add those types that we can
envisage being needed in designs *today*, without speculating about
tomorrow.  Such flexibility is the least we can do while pretending to be
"designing for the future".  If we go forward with a design that *WE KNOW
FULL WELL* is inflexible and inefficient through providing only a single
integer type, then we cannot pretend to be designing for the future at all,
it's designing for a specific application today.

> conclusively were it falls short of our needs.

There is no point going through all this IETF effort just to produce a
protocol that we know is designed for today, without even a nod for the
future.  It will be obsolete before it's released.

If we did so in ignorance, fine, we would deserve to be ignored by future VW
designers who will find our design skills so lacking in future vision.  But
we would not be doing so in ignorance.  Others in this group have commented
on the lack of future proofing in LLSD too, not just myself.  We would be
rolling out a poor types system with our eyes wide open, despite being made
aware of its lack of flexibility and extensibility.  Future VW designers
won't have any sympathy at all, we will be laughed at and condemned as
knowingly regressive.  And they would be right.

I do not believe that this group is so technically incompetent that we can't
produce a types system with a measure of flexibility and extensibility
(through negotiation at least).  What we do clearly suffer from is extreme
inertia and resistance from some participants with a regressive outlook on
protocol design, so much so that you're suggesting that we move forward with
a known inflexible system just because of our people problems here.

Well I can't help that.  I've been doing my bit for pulling the cart into
the future, despite intense opposition.  That's how engineering advances are
made, by always designing for tomorrow.  I wish a few more people here would
help with that.

Morgaine.

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

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 6 May 2011 08:46:50 +0200

Morgaine, vwrap,

 Your proposal sounds good, and  a lot more workable than starting from
scratch.  However you wrote earlier:

> Indeed, in the early days of our IETF effort, we spent months discussing
the
> width of integers in LLSD because there was only one width allowed and it
was
> hardwired in the spec.

What were the reasons to allow onl a single integer type? There must have
been a good arguments for that?

Up til now i saw suggestions for adding more integer types and for adding a
stream buffer type.
I think we should aim for keeping the set of additions as small as possible.
You suggest to add "all the usual integer types and maybe others", what
would those other types be?
Are you thinking of Dzonatas' his stream buffer type, or something else?

The version negotiation system seems to be orthogonal to adding extra types
to LLSD, i think we should  try and reach consensus on the data types
first. It indeed looks like this can be done with very little pain or delay.

-- Vaughn

On Thu, May 5, 2011 at 4:33 PM, Morgaine <[email-masked]>wrote:

>    - As Carlo has suggested in the past, add a version negotiation system
>    so that when VW projects find our 2011 set of base types inadequate, they
>    can evolve the types system and negotiate use of a newer one dynamically at
>> I am all for rigorous design, but i think i prefer actual implementation
>> of an imperfect system over sitting and waiting for an ultimate dream.
>> I am all for rigorous design, but i think i prefer actual implementation
>> of an imperfect system over sitting and waiting for an ultimate dream.
> If we did so in ignorance, fine, we would deserve to be ignored by future
> VW designers who will find our design skills so lacking in future vision.
> But we would not be doing so in ignorance.  Others in this group have
> commented on the lack of future proofing in LLSD too, not just myself.  We
> would be rolling out a poor types system with our eyes wide open, despite
> being made aware of its lack of flexibility and extensibility.  Future VW
> designers won't have any sympathy at all, we will be laughed at and
> condemned as knowingly regressive.  And they would be right.
>
> I do not believe that this group is so technically incompetent that we
> can't produce a types system with a measure of flexibility and extensibility
>> I am all for rigorous design, but i think i prefer actual implementation
>> of an imperfect system over sitting and waiting for an ultimate dream.
>> On Thu, May 5, 2011 at 12:59 AM, Morgaine <[email-masked]
>> > wrote:
>>
>>> On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol <[email-masked]>wrote:
>>>

---

From: Joshua Bell <[email-masked]>
Date: Fri, 6 May 2011 09:18:43 -0700

> been a good arguments for that?

IIRC, some of the languages we wished to support (Python comes to mind) did
not have support for integers larger than 32-bits. ECMAScript doesn't have
integer number types at all only IEEE 754 64-bit floats; if you constrain
the input and output to 32-bit integers it can represent those accurately,
but not 64-bit integers.

If you look at the history of LLSD, it started with 3 serialization formats
that explicitly specified the type of values - XML, binary, and "notation" -
a compact text serialization intermediate in size between binary and XML.
The IETF drafts dropped notation and added JSON. The JSON serialization was
"lossy" as LLSD describes types and values that don't exist in JSON
(Integer, Date, UUID, NaN, Infinity, etc). By design, though, the type
conversions described in the LLSD Draft accommodate e.g. by serializing a
Date as an ISO 8601 string, which when interpreted as a date by the receiver
results in the original Date by the string->date conversion rules. (I don't
know if we had resolved every issue with JSON serialization; certainly,
discussion about edge cases on this list never made it into a draft).

As far as adding new types: I believe there was the belief that this could
be accommodated by defining an "LLSD2" at some point in the future with a
distinct MIME type for serializations (e.g. application/llsd2+xml); unlike
the Web, content negotiation over HTTP was assumed to be functional within
VWRAP interoperation. Therefore, there was no push to ensure LLSD "v1" was
internally extensible or comprehensive for all imaginable scalar/structured
types.

Anyway... if contributors have implementation of abstract data type systems
that share characteristics with LLSD and are thinking about adding
additional scalar/structured types, they should look at the issues with both
implementation languages and serialization formats.

-- Josh

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 May 2011 13:34:30 -0700

On 05/06/2011 09:18 AM, Joshua Bell wrote:
>
> As far as adding new types: I believe there was the belief that this 
> could be accommodated by defining an "LLSD2" at some point in the 
> future with a distinct MIME type for serializations (e.g. 
> application/llsd2+xml); unlike the Web, content negotiation over HTTP 
> was assumed to be functional within VWRAP interoperation.

+1

Or, Content-Type: application/llsd+1+xml
Or, Content-Type: application/llsd++xml
Or, Content-Type: xml-ietf-vwrap/llsd+adt+extra

...etc, would work yet I believe - and + still are transient denotations 
for with or without DTD, so...

Content-Type: xml-ietf-vwrap/urn:[bank]:llsd.proxy.net:map,abstract,...

Yes, LLSD as-is continues to work even without excessive headers.

--

---

From: Morgaine <[email-masked]>
Date: Sat, 7 May 2011 05:37:34 +0100

> been a good arguments for that?
Joshua has replied about the history of it, but I'd like to reply about its
future.

When you create an ADT system and expect it to have multiple language
bindings, then you should not base your ADT's set of primitive types on your
initial choice of languages, because that introduces several very poor
consequences:

   - It reduces your set of primitive types to the lowest common denominator
   of types directly supported by your initial set of languages, and hence
   makes your ADT system a very narrow one, the opposite of "flexible type
   system".

   - It makes those initial language bindings "special" because they have
   been given special consideration, whereas further language bindings won't
   enjoy similar support as design targets.  That's not designing for the
   future.

   - It makes application developers repeatedly pay the penalty for not
   having specific types directly suited to their application, a continuing
   cost.

   - It places the burden of type poverty on all language bindings instead
   of only on the language that is type-inadequate.  Better languages have to
   suffer the penalty of an inferior one in their midst.

   - The lack of the shortest integer types impacts on binary serializations
   especially severely.  While all serializations are rendered less efficient
   when they are forced to use a single generic integer type, it is the binary
   serialization that is impacted most.  This is both unhelpful and ironic,
   since it is the binary serialization that is chosen when you want the most
   efficiency.  It is the worst possible outcome that the binary serialization
   is affected worst.

   - By requiring your most efficient language bindings (C/C++) to use fixed
   length integers instead of those that they employ internally, it reduces
   their efficiency disproportionately every time they cross the binding
   boundary.  Less efficient languages won't notice any slowdown because the
   loss of binding efficiency is masked by their overheads, whereas C/C++ have
   virtually no overheads and so are impacted most.  This is the wrong way
   around, namely designing to benefit the least efficient use case.

So given quite a number of negative consequences, what's the actual benefit
of taking the design approach described by Joshua?  Well allegedly it's so
that the initial set of languages can all represent the primitive data types
of the ADT directly, but I dispute that that goal has any merit in practice.

First of all, tying your design to the type and representational poverty of
Python and ECMAScript misses the point that your most efficient scalable
server systems are not likely to be written in them.  Clients may be written
in less efficient languages, but inefficiencies in clients don't impact on
system scalability because all those inefficiencies occur in parallel.  It's
the efficiency of server side that matters far more when designing efficient
scalable systems, so server side requirements should be considered first.
(Then bandwidth requirements next, and client requirements last.)

Secondly, it makes no sense to limit the primitive types transported by a
protocol to those which slow languages like Python and ECMAScript can
represent, because the overheads inherent in those languages vastly outweigh
any impact from protocol-language mismatch.  What's more, those languages
are not prevented from using their internal representations just because a
protocol provides shorter integers for efficiency, so it is not a valid
argument that supporting Python and ECMAScript precludes using shorter types
in the protocol.  That's just incorrect.

And thirdly, having to use a single size of integer for all purposes
introduces semantic problems which we alluded to quite recently when
discussing Service Level Semantic Interoperability --
http://www.ietf.org/mail-archive/web/vwrap/current/msg00657.html .  It's a
very bad approach at the best of times, in effect a loss of type information
for everything that is integral but is not 32 bits in length.  It results in
additional value bounds checking in the application to eliminate
inappropriate values arriving within the single-length protocol field, since
the protocol provides no direct support for any integer semantic other than
signed 32-bit.  This is bad.

I really can't see any valid reason why a protocol's primitive types would
be chosen on the basis that's been described.  It's just not a good
engineering basis.

> would those other types be?

Mostly just all the integer types, because they are the key to efficiency on
the wire and in language bindings, and they also improve the semantic
clarity.

There is only one other type missing that results in significant and common
inefficiencies, and that is bit arrays.  They are used not only for actual
bit-oriented bulk data but more frequently for carrying packed boolean
fields, like say "Restricted" and other metadata bits that we discussed
recently, and many other uses.  We're very likely to see multiple booleans
transmitted in messages, so lack of bit packing would be unfortunate for the
efficiency of our boolean serializations.  However ...

It's so hard to get any change at all agreed here that I'll waive on the bit
arrays or bit packing and just try to push the full range of integer fields.

> Are you thinking of Dzonatas' his stream buffer type, or something else?

"Stream buffer type" made no sense to me if its name accurately described
what it did.  All protocol values are immutable by definition, and hence a
field in a protocol message cannot be a buffer for anything at all.  Maybe
something else was intended, but it was never described to us so I can't
comment on it further.

> The version negotiation system seems to be orthogonal to adding extra
> types to LLSD, i think we should  try and reach consensus on the data types

Yes, it's nicely orthogonal, as long as we number our protocol as VWRAP-1 or
something like that.  And yes, it could be done with very little pain or
delay .... but it won't be.  Just watch. :DDDDDDDDDDDDD

Morgaine.

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

On Fri, May 6, 2011 at 7:46 AM, Vaughn Deluca <[email-masked]>wrote:

> The version negotiation system seems to be orthogonal to adding extra
> types to LLSD, i think we should  try and reach consensus on the data types
>>> If we don't get demonstrated commitment for specifying (and
>>> implementing!) an alternative, my vote go's to sticking with LLSD, if only
>>> to show conclusively were it falls short of our needs.
>>>
>>>
>>> If we don't get demonstrated commitment for specifying (and
>>> implementing!) an alternative, my vote go's to sticking with LLSD, if only
>>> to show conclusively were it falls short of our needs.
>>>
>>
>>
>>> If we don't get demonstrated commitment for specifying (and
>>> implementing!) an alternative, my vote go's to sticking with LLSD, if only
>>> to show conclusively were it falls short of our needs.
>>>
>>> -- Vaughn
>>>
>>>
>>> On Thu, May 5, 2011 at 12:59 AM, Morgaine <
>>> [email-masked]> wrote:
>>>
>>>>> Whereas, capabilities means more resources (as dynamic extensions
>>>>> grow); therefore, this requires minimization of number of connections
>>>>> instead of one connection per resource. Thus, that proportion leads into the
>>>>> implemented, as maximum # of connections are too easily reached without such
>>>>> mechanism.
>>>>>
>>>>>
>>>>> --

---

From: Dahlia Trimble <[email-masked]>
Date: Sat, 7 May 2011 00:45:17 -0700

I believe python supports very large integers. Try this in your python
interpreter:

>>> bigint = 2**(2**16)
>>> print bigint

I first became aware of missing integer types in LLSD when I was coding the
event queue messages to support group chat in OpenSimulator. It seems that
"region handles" are 64 bit integers in the LL protocols but are encoded as
a base64 encoded binary blob in LLSD as LLSD has no support for integers
larger than 32 bits. I suspect that changing LLSD to have larger integer
types might create some compatibility issues with existing implementations
that expect to use the binary blob.

---

From: Morgaine <[email-masked]>
Date: Sat, 7 May 2011 15:32:05 +0100

Oh dear, that's sad to hear, Dahlia.

So not only was the original premise of Python not having longer integers
wrong (although the addition of bigints may have been recent), but the
missing types in LLSD even forced SL designers to use base64 blobs in their
absence.  That strongly highlights the mistake that was made in the early
ADT.

Even worse, that design decision then went on to compromise Opensim's
implementation by forcing it to employ base64 blobs to be compatible with SL
viewers, since Opensim has no independent viewer of its own .  Such mistakes
often propagate to other parties through no fault of theirs, just because
the original design decision was not a good one.

*Well now is the time for change!
*
The IETF's Mission Statement places upon us a duty to work for the benefit
of all Internet users, so let's not perpetuate the old mistake and spread
the harm to future virtual worlds.  We have the technical competency to do
better than was done in the past.

Morgaine.

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

On Sat, May 7, 2011 at 8:45 AM, Dahlia Trimble <[email-masked]>wrote:

>> IIRC, some of the languages we wished to support (Python comes to mind)
>> did not have support for integers larger than 32-bits. ECMAScript doesn't
>> have integer number types at all only IEEE 754 64-bit floats; if you
>> constrain the input and output to 32-bit integers it can represent those
>> accurately, but not 64-bit integers.
>>
>> If you look at the history of LLSD, it started with 3 serialization
>> formats that explicitly specified the type of values - XML, binary, and
>> "notation" - a compact text serialization intermediate in size between
>> binary and XML. The IETF drafts dropped notation and added JSON. The JSON
>> serialization was "lossy" as LLSD describes types and values that don't
>> exist in JSON (Integer, Date, UUID, NaN, Infinity, etc). By design, though,
>> the type conversions described in the LLSD Draft accommodate e.g. by
>> serializing a Date as an ISO 8601 string, which when interpreted as a date
>> by the receiver results in the original Date by the string->date conversion
>> rules. (I don't know if we had resolved every issue with JSON serialization;
>> certainly, discussion about edge cases on this list never made it into a
>> draft).
>>
>> Anyway... if contributors have implementation of abstract data type
>> systems that share characteristics with LLSD and are thinking about adding

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 7 May 2011 08:02:29 -0700

or... you could simply add a version tag to the contents of the LLSD.
so, an XML LLSD blob might look like:

<?xml version="1.0"?>
<llsd>
  <version>2</version>
  ...
</llsd>

and a json blob might look like
{
  version: 2,
  ...
}

(though this example would require us to make the version element in a
map verboten.)

On Fri, May 6, 2011 at 1:34 PM, Dzonatas Sol <[email-masked]> wrote:
>> VWRAP interoperation.
> ...etc, would work yet I believe - and + still are transient denotations for
> with or without DTD, so...
>

---

From: Boroondas Gupte <[email-masked]>
Date: Sat, 07 May 2011 17:14:04 +0200

> I believe python supports very large integers. Try this in your python
In fact, python features two built-in integer types:

    * plain integers (int)
    * long integers (long)

According to the python documentation on built-in numeric types
<http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex>,
python's int is implemented using long in C. This means it has at least
32 bits, but can be larger on certain systems. E.g. on a 64bit Linux,
it'll be 64 bits long, as I've just verified myself:

    >>> import sys
    >>> 2 ** 63 - 1 == sys.maxint
    True

Python's long is unlimited in size (at the cost of performance).
Conveniently, python converts from int to long as needed, even if no
longs are amongst the operands:

    >>> sys.maxint
    9223372036854775807
    >>> sys.maxint + 1
    9223372036854775808L

(The L postfix indicates a long literal.) Conversion from long to int
doesn't happen implicitly, but can be done explicitly if wanted.

Cheers,
Boroondas

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 7 May 2011 08:19:23 -0700

Josh, it's even worse than that.

Python inherits the integer size from the compiler that generated it.
So, if you compile python on a system with a 16 bit int (which used to
be pretty common in some embedded systems) you get a version of python
that uses 16 bit ints.

I think you touched on an important aspect though... JSON is meant to
be a transfer syntax and is not supposed to make assumptions about the
sizes of types on the sending and receiving system. LLSD is more than
a transfer syntax, it's an abstract type system that DOES impose
limitations on sizes for types. Sometimes it's easy to confuse the
type system with the transfer syntax.

&c &c
m

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 7 May 2011 08:19:39 -0700

Hey Dahlia,

Yes, the way the legacy protocol handles region handles is a hack (at
best.) My suggestion has always been to, since we're creating a new
protocol, use something other than a 64 bit integer for a region
handle. IIRC, we were planning on revamping this bit of the protocol
to use a URL as a region handle to avoid the problem of requiring a
global region handle to host registry.

But that's kind of off-topic, assuming the topic is bigints in LLSD.

One of the reasons I'm not especially happy with LLSD is that it does
not distinguish between the abstract type system and the transfer
syntax. Changing the existing LLSD to support big integers would
require a modification to the binary serialization. The JSON and XML
serializations are fine, they don't add size restrictions to integer
fields at the transfer syntax level.

So you would likely have to add a new tag to the binary serialization
for "multi precision integer" which was simply a string of 32 bit ints
in network order. Or you would have to change the semantics of the
existing integer encoding to support multi precision ints. Either way
you have to change the existing LLSD binary serialization.

As a historical note, there was a bit of debate on this topic inside
the lab. One side wanted Radix 10 Floats and MP Ints and the other
side suggesting that once you opened the doors to expansion, there was
no telling where you would stop and pointing out that you can do MP
Ints as long as you bury them in binary strings. Ultimately, those of
us who supported Radix 10 floats and MP Ints were laid off before them
what supported a minimal set of types.

&c &c
m

---

From: Morgaine <[email-masked]>
Date: Sat, 7 May 2011 16:25:39 +0100

We will certainly need to have a protocol negotiation handshake if we have
any pretentions of being "extensible", and this negotiation phase needs to
be present in all serializations, including binary ones.  Carlo's advice
about this is good.

Version 1.0 for VWRAP needs to be as good as we can make it though, not the
current LLSD spec which is clearly very limited.  Knowingly keeping it
inferior and immediately creating problems for everybody is a very poor way
to proceed.

I recommend that if you want LLSD/DSD unchanged from its current spec then
you should publish it as an RFC, and avoid all these discussions.  Here in
VWRAP we have a far more onerous duty, which is to publish a *good* types
spec.

Morgaine.

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

On Sat, May 7, 2011 at 4:02 PM, Meadhbh Hamrick <[email-masked]> wrote:

> could

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 7 May 2011 07:59:29 -0700

Hey Dahlia,

---

From: Boroondas Gupte <[email-masked]>
Date: Sat, 07 May 2011 17:49:15 +0200

> be pretty common in some embedded systems) you get a version of python
Fortunately, it's not as bad as /that/. While it's true that python
inherits the integer size from the compiler, it doesn't use C's int to
implements python ints, but C's long and thus can guarantee a precision
of at least 32 bits. Also, due to seamless conversion (see my other post
<http://www.ietf.org/mail-archive/web/vwrap/current/msg00862.html>) to
python's (unlimited precision) long, the actual size of python's int (or
the implementation dependence of that size) can probably be ignored most
of the time, except maybe for performance considerations.

Cheers,
Boroondas

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 7 May 2011 08:47:29 -0700

blarg. you're right. looks like python moved from using c int's for
python ints to using c longs back in 2.2.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Sat, May 7, 2011 at 8:14 AM, Boroondas Gupte
<[email-masked]> wrote:
> plain integers (int)
> long integers (long)
> According to the python documentation on built-in numeric types, python's
> int is implemented using long in C. This means it has at least 32 bits, but
> can be larger on certain systems. E.g. on a 64bit Linux, it'll be 64 bits
> long, as I've just verified myself:
>
>>>> import sys
> Conveniently, python converts from int to long as needed, even if no longs
> are amongst the operands:
>
>>>> sys.maxint
> 9223372036854775807
>>>> sys.maxint + 1
> 9223372036854775808L
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 7 May 2011 09:57:02 -0700

well. yes. for modern python versions. i think 2.2 was the first
version to use longs instead of ints.

On Sat, May 7, 2011 at 8:49 AM, Boroondas Gupte
<[email-masked]> wrote:
> Fortunately, it's not as bad as that. While it's true that python inherits
> the integer size from the compiler, it doesn't use C's int to implements
> python ints, but C's long and thus can guarantee a precision of at least 32
> bits. Also, due to seamless conversion (see my other post) to python's
> (unlimited precision) long, the actual size of python's int (or the
> implementation dependence of that size) can probably be ignored most of the
> time, except maybe for performance considerations.
>
> Cheers,
> Boroondas
>

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 07 May 2011 10:22:05 -0700

That is why there are differences in transmit type and expect type. That 
is not obvious unless without source code. Self-documents that 
transistion possibility.

On 05/07/2011 12:45 AM, Dahlia Trimble wrote:
> I first became aware of missing integer types in LLSD when I was 
> coding the event queue messages to support group chat in 
> OpenSimulator. It seems that "region handles" are 64 bit integers in 
> the LL protocols but are encoded as a base64 encoded binary blob in 
> LLSD as LLSD has no support for integers larger than 32 bits. I 
> suspect that changing LLSD to have larger integer types might create 
> some compatibility issues with existing implementations that expect to 
> use the binary blob.
>
>
> On Fri, May 6, 2011 at 9:18 AM, Joshua Bell <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>         What were the reasons to allow onl a single integer type?
>         There must have been a good arguments for that?�
>
>
>     IIRC, some of the languages we wished to support (Python comes to
>     mind) did not have support for integers larger than 32-bits.
>     ECMAScript doesn't have integer number types at all only IEEE 754
>     64-bit floats; if you constrain the input and output to 32-bit
>     integers it can represent those accurately, but not 64-bit integers.
>
>     If you look at the history of LLSD, it started with 3
>     serialization formats that explicitly specified the type of values
>     - XML, binary, and "notation" - a compact text serialization
>     intermediate in size between binary and XML. The IETF drafts
>     dropped notation and added JSON. The JSON serialization was
>     "lossy" as LLSD describes types and values that don't exist in
>     JSON (Integer, Date, UUID, NaN, Infinity, etc). By design, though,
>     the type conversions described in the LLSD Draft accommodate e.g.
>     by serializing a Date as an ISO 8601 string, which when
>     interpreted as a date by the receiver results in the original Date
>     by the string->date conversion rules. (I don't know if we had
>     resolved every issue with JSON serialization; certainly,
>     As far as adding new types: I believe there was the belief that
>     this could be accommodated by defining an "LLSD2" at some point in
>     the future with a distinct MIME type for serializations (e.g.
>     application/llsd2+xml); unlike the Web, content negotiation over
>     HTTP was assumed to be functional within VWRAP interoperation.
>     Therefore, there was no push to ensure LLSD "v1" was internally
>     extensible or comprehensive for all imaginable scalar/structured
>     types.
>
>     Anyway... if contributors have implementation of abstract data
>     type systems that share characteristics with LLSD and are thinking
>     about adding additional scalar/structured types, they should look
>     at the issues with both implementation languages and serialization
>     formats.
>
>     -- Josh
>
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 07 May 2011 11:05:13 -0700

To answer the outstanding question,

6 million lines of code and each of them were documented in comments. I 
simply said to the outsourcer there is the problem and figure every 
comment costs $1. How much is it to hire somebody to update one line of 
code plus one comment?

I didn't get the job, yet the the outsourcer did! Amicable.

On 05/07/2011 10:22 AM, Dzonatas Sol wrote:
> That is why there are differences in transmit type and expect type. 
> That is not obvious unless without source code. Self-documents that 
> transistion possibility.
>
>
>> I believe python supports very large integers. Try this in your 
>> python interpreter:
>>
>> >>> bigint = 2**(2**16)
>> >>> print bigint
>>
>> some compatibility issues with existing implementations that expect 
>> to use the binary blob.
>>
>>

--

---

From: Morgaine <[email-masked]>
Date: Sun, 8 May 2011 03:22:32 +0100

On Sat, May 7, 2011 at 4:19 PM, Meadhbh Hamrick <[email-masked]> wrote:

> syntax.

I agree 100%.  If one has the worthy goal of defining a semantically
complete ADT system, then the last thing one should do is to couple it to
specific serializations, and even less to specific language bindings.  That
was a total mistake in LLSD in practical terms.

If you want to make a types system efficiently implementable, then stick to
the requirements of hardware architectures which evolve slowly over decades,
like x86.  Languages evolve to much shorter timescales, and a good ADT
system should be usable with whatever language comes along.

Furthermore, efficient serializations and languages are devised all the time
because efficiency is a much-sought engineering goal.  Unless you provide
your ADT system with all the normal primitive types for the common hardware
architectures, you are inherently discriminating against the most efficient
serializations and languages,

LLSD is guilty of this, which is what I'm trying to correct for VWRAP.  It's
not hard to achieve, but it needs the will for progress.

Morgaine.

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

On Sat, May 7, 2011 at 4:19 PM, Meadhbh Hamrick <[email-masked]> wrote:

> >> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <[email-masked]
> >
> >> wrote:
> >>>

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 07 May 2011 19:55:12 -0700

I vote nay on Morgain's attempt at "social engineering" LLSD code any 
further, especially in the eyes and ears of IETF's Trust, replacement of 
LLSD with "ADT" and such semantics is out of scope. Let's continue our 
mutations (IL) and evolve!

Morgaine, you seem to have an invested interest in specific hardware. We 
need simple, language agnostic (VM) approaches, not language specific 
approaches. Please keep this simple to additional types or 
clarification. DSP does not always means dynamic signal processor.

On 05/07/2011 07:22 PM, Morgaine wrote:
> Furthermore, efficient serializations and languages are devised all 
> the time because efficiency is a much-sought engineering goal.� Unless 
> you provide your ADT system with all the normal primitive types for 
> the common hardware architectures, you are inherently discriminating 
> against the most efficient serializations and languages,
>
> LLSD is guilty of this, which is what I'm trying to correct for 
> VWRAP.� It's not hard to achieve, but it needs the will for progress.

--

---

From: Morgaine <[email-masked]>
Date: Sun, 8 May 2011 04:45:37 +0100

On Sun, May 8, 2011 at 3:55 AM, Dzonatas Sol <[email-masked]> wrote:

> We need simple, language agnostic (VM) approaches, not language specific
> approaches.

It appears that you haven't understood what I've written.  I'm arguing *
against* the language-specificity upon which LLSD was designed, and
broadening its primitive data types so that all languages are supported
well, including the most efficient ones.

Apparently you agree with me, according to your last statement.

The current LLSD was designed on the basis that its primitive data types
were supported directly by type empoverished languages like Python and
ECMAscript, as Joshua explained to us.  That language-specific approach is
extremely poor, and results in inefficient serializations and inefficient
bindings to the most efficient languages.

That needs to be corrected so that future virtual worlds don't suffer from
the poor design approach used previously.

Morgaine.

On Sun, May 8, 2011 at 3:55 AM, Dzonatas Sol <[email-masked]> wrote:

> approaches. Please keep this simple to additional types or clarification.
> DSP does not always means dynamic signal processor.
>
>
>> Furthermore, efficient serializations and languages are devised all the
>> time because efficiency is a much-sought engineering goal.� Unless you
>> provide your ADT system with all the normal primitive types for the common
>> hardware architectures, you are inherently discriminating against the most
>> efficient serializations and languages,
>>
>> LLSD is guilty of this, which is what I'm trying to correct for VWRAP.�
>> It's not hard to achieve, but it needs the will for progress.
>>
>
>
> --

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 07 May 2011 21:38:20 -0700

On 05/07/2011 08:45 PM, Morgaine wrote:
> It appears that you haven't understood what I've written.

Somehow that creation attempt of yours is some magical license to 
endlessly straw man without identification. I think the good book exists 
about that already.

Don't even start me on how your "social engineering" proposal could 
affect the colleges and treatment of children or child labor within your 
walled garden utopia of future virtual worlds. Even you say "that is not 
how it works" yet you want to change the past... the real past? Let me 
guess...   *whoosh* ...like none of that ever happened or came close.

I wonder if U.C. Berkeley Law studies France's law code on 
microeconomics, and if IETF might fork such license representation... 
for...  homework as assets.

--

---

From: Morgaine <[email-masked]>
Date: Sun, 8 May 2011 05:57:34 +0100

I have no idea what you're talking about Dzon, but it's a rant and not
technical.  We're meant to be discussing a technical topic here.

On the technical topic of LLSD design, earlier you wrote "*We need simple,
language agnostic (VM) approaches, not language specific approaches*", which
is exactly the position that I've been maintaining throughout all of this.
I'm glad to hear that you agree.

Joshua confirmed the language-specific design origins of LLSD for us, so
there is no doubting that.  It has led even Linden Lab into problems like
having to represent handles as a base64 blob through lack of longer integer
types than 32 bit.  It was a poor design decision even for its originators.

VWs further down the road will need a more flexible ADT system to express
their needs and to allow more efficient serializations and language bindings
to be created.  That's why I'm trying to lose the language specificity of
LLSD's past and give us more flexible data types to support efficient
serialization and fast languages.

Morgaine.

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

On Sun, May 8, 2011 at 5:38 AM, Dzonatas Sol <[email-masked]> wrote:

> Somehow that creation attempt of yours is some magical license to endlessly
> straw man without identification. I think the good book exists about that
> already.
>
> Don't even start me on how your "social engineering" proposal could affect
> the colleges and treatment of children or child labor within your walled
> garden utopia of future virtual worlds. Even you say "that is not how it
> works" yet you want to change the past... the real past? Let me guess...
> *whoosh* ...like none of that ever happened or came close.
>
> I wonder if U.C. Berkeley Law studies France's law code on microeconomics,
> and if IETF might fork such license representation... for...  homework as
> assets.
>
>
>
> --
>

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 08 May 2011 04:52:43 -0700

Morgaine, please provide exact text here in the list of what you want 
updated. There are already enough motion to keep scalar data as scalar.

If that alone is too hard to comprehend, then your "designing for the 
future" ignores complete backward compatibility and the many 
implementations that already exist. My last post is only on topic of the 
IETF interest even if merely stated in the obvious truths, just not in 
words you could twist so easily.

We only need simple agreement/disagreements, not staged assignments. 
Because of that alone, I can't take you seriously on any scale, even 
when the scope is pushed completely to the limits.

Please, just provide your draft-adt-00... so we can focus on consensus 
and scale.

--

---

From: Morgaine <[email-masked]>
Date: Sun, 8 May 2011 13:38:12 +0100

On Sun, May 8, 2011 at 12:52 PM, Dzonatas Sol <[email-masked]> wrote:

> updated.

That's what we're working on right now.  I don't have exact text, we're
working out the details first on the list, and once we have those worked
out, and we see a consensus forming, then we can start writing an updated
document ready for the next draft.

> There are already enough motion to keep scalar data as scalar.
>

I don't know what that means.

> future" ignores complete backward compatibility and the many implementations
> that already exist.

We are not designing for backwards compatibility, and there are no
implementations of any VWRAP protocol yet, not even of VWRAP's ADT system
which is currently still being defined.  You're confusing two different
"LLSD".

The LLSD that is in current use in Second Life and in OpenSimulator is not
the ADT system that we are creating for VWRAP --- there is just a
coincidence of names currently, because Linden's LLSD was used as the
starting point for our work.  That name needs to change to avoid the
confusion that you've just demonstrated.  Meadhbh has renamed her ADT system
to "DSD", but if her system is not amenable to change for the purposes of
VWRAP then we can't use that name either.

Nothing that we do here is going to affect the LLSD that is employed by
Linden Lab, and Opensim will almost certainly continue to use that same LLSD
for compatibility with SL.  We don't have the power to alter their LLSD,
even if we wanted to (which we don't).  This has been explained here many
times already.

The above probably highlights the urgency with which we need to adopt a
different name for VWRAP's ADT system.

> My last post is only on topic of the IETF interest even if merely stated in
> the obvious truths, just not in words you could twist so easily.
>

 I don't know what that means.

> Because of that alone, I can't take you seriously on any scale, even when
> the scope is pushed completely to the limits.
>
>
 I don't know what that means.

> Please, just provide your draft-adt-00... so we can focus on consensus and
> scale.
>
>
I don't know what you mean by "scale" here.  Regarding the draft, we're
still working out what the next draft of our ADT system should contain.
Your help would be appreciated, but if you aren't interested in improving
the ADT system for VWRAP then at least please don't block us from working on
it.

Morgaine.

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

On Sun, May 8, 2011 at 12:52 PM, Dzonatas Sol <[email-masked]> wrote:

> future" ignores complete backward compatibility and the many implementations
> that already exist. My last post is only on topic of the IETF interest even
> if merely stated in the obvious truths, just not in words you could twist so
> easily.
>
> Because of that alone, I can't take you seriously on any scale, even when
> the scope is pushed completely to the limits.
>
> Please, just provide your draft-adt-00... so we can focus on consensus and
> scale.
>
>
> --

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 08 May 2011 08:47:37 -0700

Start with the solution (and the charter).

On 05/08/2011 05:38 AM, Morgaine wrote:
> "I don't have exact text, we're working out the details first on the 
> list, and once we have those worked out, and we see a consensus 
> forming, then we can start writing an updated document ready for the 
> next draft."

We need "best effort" first brought to the table. If you have something 
you can bring to this list and kill() if that something goes completely 
wrong, perfect enough. If you try to build something here first, then 
you don't have something OF YOUR OWN to kill.

 > "...please don't block us from working on it."

Please, don't try to turn this around back in the opposite direction 
again and blame biosystematicals on me. If you want to go in the 
opposite direction, the bring what you already have to the table.

 > "You're confusing two different "LLSD"."

We have not confused multiple licenses. Others on this list (and other 
WGs) have demonstrated awareness of this and don't cross-judge this 
documentation based on theirs or others implementation.

Blackbox the details on another list. Clarify the protocol on this list. 
Simple. Also note, some of us are doctors and some of us are scientists. 
There are reasons we don't share the pen, as this principle alone kills 
the obvious argument. Please consider *at least this much* about the pen 
with everything you write here. If you want to write the draft, then be 
the doctor! Don't kill() others scientists.

Dear Happy Mothers Day, thanks for the most awesome academy!

--

---

From: Morgaine <[email-masked]>
Date: Sun, 8 May 2011 17:57:06 +0100

> Start with the solution (and the charter).
Sorry, but no.  You start with the requirements, or you'll get the wrong
solution.  Starting with the solution was what we did with OGP, and look
where it landed us.  After 2 years of work, we had to throw most of it away
because it didn't meet the central goal of providing interop between
worlds.  Let's not make that mistake again.

The same applies to our ADT system.  It has to meet important engineering
requirements, and the big ones are flexibility, extensibility, and
scalability, plus the efficiency that everybody needs.  The initial ADT
system of our first draft fails on all three relevant counts (scalability is
affected only through efficiency), which is why we're addressing those
defects now.

> wrong, perfect enough. If you try to build something here first, then you
> don't have something OF YOUR OWN to kill.
>

No idea what most of that means, but the "best effort brought to the table"
I did understand, and we're working that out currently to our best efforts.
In particular, note the exchange of posts about this with Vaughn, including
http://www.ietf.org/mail-archive/web/vwrap/current/msg00853.html ,
http://www.ietf.org/mail-archive/web/vwrap/current/msg00855.html  and
http://www.ietf.org/mail-archive/web/vwrap/current/msg00858.html .  The
discussion has been a good one, aided also by contributions from Joshua,
Meadhbh, Dahlia and Boroondas.  It has been a technical discussion, and it
has been leading us forward.  You clearly don't want to contribute
technically on this topic, which is your choice, but don't accuse the rest
of us of bringing nothing to the table.  We're working on it, productively,
and the discussion has been entirely technical with the other participants.

> Please, don't try to turn this around back in the opposite direction again
> and blame biosystematicals on me. If you want to go in the opposite
> direction, the bring what you already have to the table.

I've got no time for this.  Stick to technical topics please.

> We have not confused multiple licenses. Others on this list (and other WGs)
> have demonstrated awareness of this and don't cross-judge this documentation
> based on theirs or others implementation.
>
> There are reasons we don't share the pen, as this principle alone kills the
> obvious argument. Please consider *at least this much* about the pen with
> everything you write here. If you want to write the draft, then be the
> doctor! Don't kill() others scientists.

Licenses have nothing to do with this.  And stick to technical topics
please.

Morgaine.

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

On Sun, May 8, 2011 at 4:47 PM, Dzonatas Sol <[email-masked]> wrote:

>> "I don't have exact text, we're working out the details first on the list,
>> and once we have those worked out, and we see a consensus forming, then we
>> can start writing an updated document ready for the next draft."
>>
>
> We need "best effort" first brought to the table. If you have something you
> can bring to this list and kill() if that something goes completely wrong,
> perfect enough. If you try to build something here first, then you don't
> have something OF YOUR OWN to kill.
>
> Please, don't try to turn this around back in the opposite direction again
> and blame biosystematicals on me. If you want to go in the opposite
> direction, the bring what you already have to the table.
>
>
> We have not confused multiple licenses. Others on this list (and other WGs)
> have demonstrated awareness of this and don't cross-judge this documentation
> based on theirs or others implementation.
>
> There are reasons we don't share the pen, as this principle alone kills the
> obvious argument. Please consider *at least this much* about the pen with
> everything you write here. If you want to write the draft, then be the
> doctor! Don't kill() others scientists.
>

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 08 May 2011 10:30:43 -0700

On 05/08/2011 09:57 AM, Morgaine wrote:
> It has to meet important engineering requirements, and the big ones 
> are flexibility, extensibility, and scalability, plus the efficiency 
> that everybody needs.�

(previously) "I don't know what you mean by "scale" here."

BIG technical topic: "scalability" versus "scale" versus "scalar".

> Licenses have nothing to do with this.� And stick to technical topics 
> please.

Again, start with the solution.  SLDC....

--

---

From: Morgaine <[email-masked]>
Date: Sun, 8 May 2011 18:42:06 +0100

I should have mentioned Carlo's contribution on this topic too, namely to
gain extensibility through version negotiation at protocol initiation time.
This allows us to avoid having to add extensible predefined types to the ADT
system, a clear win.

This doesn't mean that we should feel free to make VWRAP's ADT system v1.0
totally poor, but it does mean that if we fail to make it meet common
requirements then our incompetence can be overcome by developers without
coming back to the IETF.

Morgaine.

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

On Sun, May 8, 2011 at 5:57 PM, Morgaine <[email-masked]>wrote:

>>> list, and once we have those worked out, and we see a consensus forming,
>>> then we can start writing an updated document ready for the next draft."
>>>
>>

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 08 May 2011 15:13:16 -0700

Note, thinking-out-of-the-box discussion about hetero-generous region 
hubs. Besides the <embed> tag, there still is need for presence in the 
secondary region where the are assets are actually left in the original 
region.

Please stay tune while we/they... unplug off-list and plug-in Monday's 
asset.

SDLC... I vote to add (indeterminate named) multi-cast ability to such 
plug-in regions in the charter. The constraint is more obvious 
connections and update-frames of such regional topology. I think 
'regional media extensions' is more in scope than abstract client-side 
media extension. Should we assume such media extensions are out of scope?

--

---

From: "Robert G. Jakabosky" <[email-masked]>
Date: Mon, 9 May 2011 00:12:49 -0700

On Sunday 08, Dzonatas Sol wrote:
> implementations that already exist.

-1

Why should VWRAP keep backwards compatibility to anything when we haven't even 
published a standard yet.  The current LLSD spec is a draft and not set in 
stone.  Current LLSD implementations may have to change before this 
standardization process is finished.

-- 
Robert G. Jakabosky

---

From: Morgaine <[email-masked]>
Date: Mon, 9 May 2011 12:59:21 +0100

Indeed Robert.  We're defining a new ADT system for VWRAP, and LLSD was
merely the initial input.

I think we should call the types system that we're defining something like
VWRAP-ATS (VWRAP Abstract Types System), to avoid it being confused with the
current LLSD.

Despite repeated explanation that nothing we define here will alter the LLSD
employed by Second Life (we don't have the power to do that), people still
fail to distinguish between our ADT system and Linden's.  Only a new name
will fix that ambiguity.

Morgaine.

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 09 May 2011 07:21:10 -0700

> standardization process is finished.

Standards and implementation is like any 2 step process that remains 
separate. If you give priority to one over the other then it'll cost you 
or someone more. Just because we create the blackbox process to 
accomplish this doesn't mean we ignore each others needs or what has 
been already done.

Why make-up standard for something that never has been implemented? 
You'll probably find you didn't even need the standard and that there is 
something else that already fits your need.

We can't create the blackbox process without implementation.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 09 May 2011 08:02:50 -0700

Morgaine, you haven't shown to trust LLSD as-is.

We need that much published so we can move on with what developers have 
already done for the last few years to share implementation of LLSD. 
They just have their hands tied and can't express their interest.

Then you can play with another WIP/RFC after that much is done. I don't 
see why you continue to argue to get rid of LLSD as-is. How can we trust 
you and what you want to write? You have ignored those that want to keep 
LLSD as-is.

This is why I motioned earlier to go ahead and publish the type system 
as-is because your desire to innovate from that "standard" (as-is) 
weighs-in on the reason why to keep LLSD as-is. It makes more sense this 
way.... historical.

On 05/09/2011 04:59 AM, Morgaine wrote:
> Indeed Robert.� We're defining a new ADT system for VWRAP, and LLSD 
> was merely the initial input.
>
> I think we should call the types system that we're defining something 
> like VWRAP-ATS (VWRAP Abstract Types System), to avoid it being 
> confused with the current LLSD.

--