[LV2] Simplifying the Atom model

[Stefan Kersten]

hi david,

On 09/02/2013, at 02:52, David Robillard <d at drobilla.net> wrote:
> 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).

imho the current scheme is not confusing at all but rather makes the distinction between blanks and resources explicit instead of relying on a convention.

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

i'd say leave it like it is ...

sk