[LV2] Simplifying the Atom model

[David Robillard]

On Sun, 2013-02-10 at 23:00 +0100, Stefan Kersten wrote:
> On 10/02/2013, at 21:30, David Robillard <d at drobilla.net> wrote:.
> >>> As does the examples, as do a ton of plugins that copy them.
> >>> 
> >>> Seems clear this is just generally more of a nuisance, what's the
> >>> advantage?  There is the argument that it shouldn't be changed just
> >>> because it shouldn't be changed, but in general it seems pretty clear to
> >>> me now that this way sucks, the type hierarchy is weird and pointless.
> >> 
> >> imo the current design, which makes an explicit distinction between distinct datatypes is better than merging the types but having different semantics of the type field depending on its value (not only affecting the atom but also the urid extension). the nuisance you refer to above could be alleviated by adding one helper function to atom.h.
> > 
> > But they *aren't* distinct data types!  That is the point.  They are
> > exactly the same datatype.
> > 
> > It is a straight up incorrect model.  Blank nodes and named resources
> > are *not* a different type of thing.  They just have a different kind of
> > ID.
> 
> ok, i see now! what are blank node ids used for anyway in existing code atm?

By far the most common use case is for sending messages, where you don't
care about the ID of the message, so they are usually blank.  For
example the patch extension defines vocabulary so you can send a message
to set a property, like:

[]
    a patch:Set ;
    patch:property foo:awesomeness ;
    patch:value 9999999.0 .

Because of this type hierarchy, in code this means you have to make a
"blank".  This confuses people, without the context of this
conversation, what is a "blank"?  An RDF nerd might figure it out, but
the 99% audience of LV2 hackers won't.

Object, on the other hand, would be much clearer ("Dict" perhaps even
clearer, but I left that alone in case we want a dict with non-URI keys
in the future).  "Object" is analogous to JSON's which is nice.

We basically have a simple data model here with a bunch of primitives,
and two main containers: Object, and List ("Tuple", oops).  A simple and
elegant thing in theory, but it comes across as anything
but.  Since it will increasingly become more and more important, any
potential simplification of it is very desirable...

Cheers,

-dr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130210/7a1349e6/attachment-0002.pgp>