[LV2] Reducing URI mapping burden / staticification
ventosus at airpost.net
Thu Sep 29 01:16:44 PDT 2016
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
> 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...
More information about the Devel