[LAD] "enhanced event port" LV2 extension proposal

[Krzysztof Foltman]

Dave Robillard wrote:

> Not really 'nicely'... essentially implementing the exact same thing n
> times.  Why bother?

Huh???

Instantiating n times, not implementing.

I know there are certain bad programmers around who would implement it
multiple times or use copy-paste for "code reuse", but I don't think
they make LV2 hosts.

>> 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?
> The interface for the dynamic part would have to be figured out before
> this can be decided.

??? Well, just proposed one. I don't know if it's the best one, as
nobody proposed any alternative, but it certainly works.

> ... did I stumble on to the Java 101 mailing list by mistake? ;)

Do you think interfaces are a Java thing?

Hint: IDL. Makes some explanations shorter. Also, allows us not to get
distracted by details like if "user data" should be passed as void * or
struct * or integer cookie or anything else.

If there are *really* people who don't get it (shouldn't have been
sleeping through OOP courses :P), let me translate it, say, to C:

/******* functions in IURIRegistryObserver_funcs are only implemented by
the plugin when it wants notifications about new types ****************/

struct IURIRegistryObserver;

struct IURIRegistryObserver_funcs
{
  // function in a plugin called by host on new URI registration
  void (*mapping_added)(struct IURIRegistryObserver *observer, int id,
const char *uri);
};

struct IURIRegistryObserver
{
  struct IURIRegistryObserver_funcs *functions;
  // plugin may place it in a larger structure, and cast a pointer
};

/* functions implemented by host, used for mapping URIs and numbers */

struct IURIRegistry_funcs
{
  // returns -1 if new registrations are not supported
  int (*uri_to_id)(struct IURIRegistry *registry, const char *uri, bool
create_if_absent);

  // returns pointer to the URI (host-owned), or NULL
  const char *(*id_to_uri)(struct IURIRegistry *registry, int id);

  // might be a do-nothing if the host doesn't support registering uris
on the fly

  void (*add_observer)(struct IURIRegistryObserver *observer);

  // might be a do-nothing if the host doesn't support registering uris
on the fly
  void (*remove_observer)(struct IURIRegistryObserver *observer);
};

/* structure returned by get_registry */
struct IURIRegistry
{
  struct IURIRegistry_funcs *functions;
  // host may place it in a larger structure, and cast a pointer
};

// structure on host side
struct IURIRegistries_funcs
{
  struct IURIRegistry *get_registry(const char *uri);
};

// structure on host side
struct IURIRegistries
{
  IURIRegistries_funcs *functions;
  // host may place it in a larger structure, and cast a pointer
};

Or to C++:

class IURIRegistryObserver
{
  virtual void mapping_added(int id, const char *uri) = 0;
};

class IURIRegistry
{
  virtual int uri_to_id(const char *uri, bool create_if_absent) = 0;
  virtual const char *id_to_uri(int id) = 0;
  virtual void add_observer(IURIRegistryObserver *observer) {}
  virtual remove_observer(IURIRegistryObserver *observer) {}
};

class IURIRegistries
{
  virtual IURIRegistry *get_registry(const char *registry_uri) = 0;
};

In fact, instead of IURIRegistries* you may have separate feature per
registry. Doesn't matter much.

Perhaps you want reference implementation, too? :D

Krzysztof