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

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 :) ):

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Dec 4 12:15:02 2007