[LAD] "enhanced event port" LV2 extension proposal
wdev at foltman.com
Tue Dec 4 09:42:37 UTC 2007
Dave Robillard wrote:
> Using a uint32_t (which is a reasonable limit for number of symbols in
> pretty much any system) and just not using out of range numbers for the
> event ones doesn't seem so bad, just in case. It's one line in a
> comment somewhere, BFD.
I'm thinking of something else - like having different "domains" for
mappings. Like http://whatever/parameter-value gets number 10 in
URI-to-event-type mapping, and number 16777216 in URI-to-global-numbers
mapping. Basically, same class (URI-to-int mapper), different objects
(event type URI registry, plugin port URI registry, plugin URI registry,
and so on). Different dictionaries, same dictionary interface.
I'm not insisting this is a good idea - just that it could solve the
"max 65536 types" thing nicely while preserving some (not all)
generality. It could also lead to a mess if somebody used wrong type ID
(when the same URI is in two registries).
Also, I would be for a requirement that numbers are always assigned (by
host) sequentially starting from 0, not by - for example - hashing,
because then some plugins could use small arrays to store
event-type-to-handler mapping (or
something-id-to-whatever-data-structure). Is that OK?
Seems that we don't have as many ideas for design of URI-int mapping as
we had for binary layout ;)
What about this (translate it to C in your heads :) ):
// function in plugin etc. called by host whenever new URI is registered
void mapping_added(int id, const char *uri);
int uri_to_id(const char *uri, bool create_if_absent);
const char *id_to_uri(int id);
void add_observer(IURIRegistryObserver *observer);
void remove_observer(IURIRegistryObserver *observer);
IURIRegistry *get_registry(const char *registry_uri);
Where IURIRegistries pointer is passed as a feature to a plugin.
Either that, or expose individual IURIRegistry objects as separate
features (perhaps deriving from http://something/uri-registry, RDF
allows that, right?).
Note that there is no delete function, as is doesn't seem very useful
for our purposes. Otherwise, it should be fine.
More information about the Linux-audio-dev