[Devel] Fwd: [RFC] URID extension

[David Robillard]

On Fri, 2011-07-22 at 13:35 -0500, Gabriel Beddingfield wrote:
> Oops... I accidentally replied off-list.
> 
> ---------- Forwarded message ----------
> From: Gabriel Beddingfield <gabrbedd at gmail.com>
> Date: Thu, Jul 21, 2011 at 2:16 PM
> Subject: Re: [Devel] [RFC] URID extension
> To: David Robillard <d at drobilla.net>
> 
[...]
> Why would a plugin need to or want to unmap a URI?

To e.g. serialise state to a file or for network transmission, or simply
for debugging messages.  Essentially anywhere that URIs are used more
dynamically than a simple case-like statement comparing against a small
fixed set of known URIs.

>   And if plugin A
> maps the uri, then then plugin B maps/refers to the same one... what
> happens when A unmaps the URI?

Hm, interesting point.  My initial thought was "hm, all plugins would
have to share a URI map, but this is both unfortunately restrictive and
difficult to define".  However, I think the host can just deal with
this.  Assuming all URIs come from the host (e.g. the types of events
the host sends the plugin), it can assume all URIs coming out of that
plugin use the same map, it implicitly knows the context.

However, this is pedantry.  In general: all plugins share the same map.
Eliminating multiple contexts is essentially our goal here, so a single
map assumption is a given.

> Thus, I was thinking that unmapping would be an implementation detail
> of the host implementation... based on a reference counting scheme.

I am not sure how reference counting is related.

Unmapping is simply the inverse of mapping.  Mapping = "URI string to
integer", unmapping = "integer to URI string".  The requirement for
unmapping does add an implementation burden on the host, since a simple
single map data structure (dict, hash, tree, whatever) can't do it.

Here is one very simple zero-dependency C data structure that can do
both ways:

http://svn.drobilla.net/lad/trunk/jalv/src/symap.h
http://svn.drobilla.net/lad/trunk/jalv/src/symap.c

See comments for a discussion of the performance trade-offs.

-dr