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

[Dzonatas Sol <[e-mail]>]

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


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