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

[Morgaine <[e-mail]>]

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 <[e-mail]>wrote:

> 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.
>
>
> On Fri, May 6, 2011 at 9:18 AM, Joshua Bell <[e-mail]> wrote:
>
>> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <[e-mail]>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, 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
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>