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

[Meadhbh Hamrick <[e-mail]>]

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
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Sat, May 7, 2011 at 12: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
>
>