[LV2] Simplifying the Atom model
sk at k-hornz.de
Sat Feb 9 03:40:33 PST 2013
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 ...
More information about the Devel