[LV2] Reducing URI mapping burden / staticification

[Hanspeter Portner]

On 26.09.2016 20:01, David Robillard wrote:
> 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?

Sounds great.