Re: [vwrap] What abstract type systems already exist?

[Morgaine <[e-mail]>]

On Mon, May 9, 2011 at 9:36 PM, Boroondas Gupte
<[e-mail]>wrote:

>
> *What abstract type systems do currently exist *("exist" as in published
> and sufficiently documented. Don't have to be formally standardized, though
> if they are, that's a plus.)* and how do they compare to LLSD?*
>


Fantastic question!  It could easily form the basis of a worthy MSc thesis
too. :-)

For our purposes, since we have a very practical goal, I'll narrow this
response down to a very short one by eliminating all those that are
programming language-specific (many languages allow you to define your own
ADTs within them), and focus on the most popular language-agnostic ADTs that
have numerous implementations and language bindings.  It's going to be an
impressively short response because I'm just going to link to a useful
Wikipedia article. :P

It needs to be stated that because our interest is in practical
implementations only, in practice your question becomes almost identical to
asking about popular serialization systems.  Behind every serialization
system there is a types system, but the opposite is not necessarily true.

Before I do that though, let me point out the single most widely deployed,
best documented, and most standardized abstract types and serialization
system on the planet, which also happens to be one of the oldest on the
Internet, *ASN.1*  --- http://en.wikipedia.org/wiki/ASN.1 (official
standards documents are linked in the article).

How does ASN.1 compare to LLSD?  It's hugely more flexible, much more
efficient, arbitrarily extensible, and unlimited in the precision of its
primitive types.  (The recent newcomers Protocol Buffers and Thrift actually
borrow quite a few tricks from it.)

Beyond that, take a quick look at the Wikipedia article on "Comparison of
data serialization formats", which lists a very useful selection of those
that are "notable":
http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats .  As
you'll note, quite a few of them have official standards, some informational
RFCs, and others have high popularity despite only informal documentation.

There is certainly no lack of candidates. :-)


Morgaine.




=======================

On Mon, May 9, 2011 at 9:36 PM, Boroondas Gupte
<[e-mail]>wrote:

>  On 05/08/2011 03:47 AM, Morgaine wrote:
>
> ADT means Abstract Data Type.
> [...]
> No mystery there, it has been so for decades of common usage in Computing.
> :-)
>
> On 05/09/2011 03:53 PM, Meadhbh Hamrick wrote:
>
> hmm... don't think me or mark lentczner coined the term "abstract type
> system." i was used by the OMG and Microsoft long before we used it.
>
>  On 05/09/2011 03:58 PM, Morgaine wrote:
>
> Aye, that phrase has been in use for as long as types systems have existed.
>
>
> As the concepts of both, ADTs and ATSs have apparently existed longer
> already than I assumed, I guess there must be ATSs other than LLSD. As a
> basis for decisions, it'd be useful to have some overview. So my question
> is:
> *What abstract type systems do currently exist *("exist" as in published
> and sufficiently documented. Don't have to be formally standardized, though
> if they are, that's a plus.)* and how do they compare to LLSD?*
>
> For each such ATS, it'd be useful to know:
>
>    - How flexible is it?
>    (Could it be used for VWRAP? For that, its set of types probably must
>    already be designed for general purpose or (like LLSD) with typical virtual
>    world data in mind.)
>    - Is it extensible? How does the extension mechanism work?
>     - Are there serializations defined for it? If so, which ones?
>    - How entangled is the ATS itself with the serializations?
>    - How simple is it? (Both conceptually and for implementors of
>    (de)serializers etc.)
>
> Once we have collected that, we'd be in a better position whether to use
> LLSD (as-is) or one of the other systems or whether to create our own
> (probably based on LLSD and/or other ones).
>
> Cheers,
> Boroondas
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>