[LV2] Simplifying the Atom model

David Robillard d at drobilla.net
Fri Feb 8 17:52:35 PST 2013

I think the Atom data model is a bit more complex than it needs to be.
With a reason, but I think with some experience it might be best to just
change that reason.

The issue is Object/Blank/Resource.  Essentially these are 3 types for
the same thing, a dictionary-with-uri-keys (in RDFglish this is a
"Resource").  The separate classes are needed because a blank has no
URID, but a Resource does.  They both have a uint32_t type, but with
different meaning.

Necessary because URIDs are uint32_t, but in practice having these
separate types sucks, and Atom is more confusing than it should be
because of it.  Particularly since Blank is used for all high level
communication (e.g. UIs sending messages to plugins), it's a bad area to
be confusing.

In short, I think it would be much more obvious if we simply had one
"Object" type.

The solution is to merge the classes, and use a signed int32_t as an ID,
where positive is a URID, and negative is a blank node ID (essentially
meaningless outside local context).

This would basically require hosts to cap their URID implementations at
int32_t, which could be defined as a feature but AFAIK most use
sequential numbers anyway.  That does mean you can't use GQuark or a
32-bit pointer implementation for free, though...

Actually making this change would introduce the minor compatibility
hiccup of changing the signedness of the IDs in the atom extension.  A
little naughty, but I don't think that would have any consequences other
than compiler warnings...

So, though I know few have opinions on the Atom stuff yet, this is me
trolling for them: make it so there is one Object class, and use a
int32_t as an ID for it regardless, or leave things be?


-------------- 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/20130208/e75aab19/attachment.pgp>

More information about the Devel mailing list