[LV2] Reducing URI mapping burden / staticification

[David Robillard]

I've been thinking about this lately, and since it has come up in
another thread:

Lately I've been trying to clean up and condense some plugins to
notice/eliminate as much noise/boilerplate/etc as possible (and/or
things that make LV2 "weird" or "annoying" or whatever).  When you get
to a certain point, mapping URIDs starts to become the most significant
issue.

Additionally, in much implementation work around atoms I've found the
fact that types are dynamically assigned seriously troublesome.  A good
example of this is making wrappers or bindings.  if you wanted to, say,
make C++ bindings, you want a class that can get you an Atom from an int
or float (etc), but you can't make a clean mostly-transparent class to
do this because you need the mapping facility from the application/hosts
to be able to create them at all.

It would be convenient if atom types were just static (good ol' enums),
but I still think URI mapping is a great idea, and using it only in some
places and not others is ugly.  So, can we have both?

I think, for things in the official spec at least, we can, with
something like this:

- Add a feature that requires the URI map to never return an ID below
some value
- Define/maintain a value in the spec that is the maximum "static URID"
in the spec
- Define all URIs in the spec headers as enums or static URIDs with
explicit values that are always below this value

The URI map would be required to still map URIs below this value (easy
enough if the spec would have to provide things in a form that make this
trivial), so nothing breaks, but we can now pretend like things in the
LV2 spec are static and not have to bother with mapping URIs for those
concepts whatsoever, though all the advantages of mapped URIs
(extensibility and so on) are still there.  Seems pretty nice to me.

One issue is that plugins and hosts need to agree what that maximum
static URID value is (if they every communicate/compare them anyway).
The host can provide this information as a feature, which is easy
enough.  I'm not sure how to handle the case where they don't match, but
this number is from the spec, so essentially that's a "the host was
built against too old of a version of LV2 for this plugin" and the
plugin can just fail to instantiate...

Thoughts?

-- 
dr