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

[Morgaine <[e-mail]>]

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

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



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

> 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
> >
> >
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>