Re: [LAD] "enhanced event port" LV2 extension proposal

Dave Robillard wrote: 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 :) ): interface IURIRegistryObserver { // function in plugin etc. called by host whenever new URI is registered void mapping_added(int id, const char *uri); }; interface IURIRegistry { 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); }; interface IURIRegistries { 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. Thoughts? Krzysztof