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

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

On Fri, May 6, 2011 at 9:18 AM, Joshua Bell <josh@lindenlab.com> wrote:
> On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca <vaughn.deluca@gmail.com>
> 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
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>