[Devel] uri-map: what is the `map` parameter for?
d at drobilla.net
Mon Jul 18 15:21:46 PDT 2011
On Mon, 2011-07-18 at 16:46 -0500, Gabriel Beddingfield wrote:
> On Mon, Jul 18, 2011 at 4:35 PM, David Robillard <d at drobilla.net> wrote:
> > Basically an extremely stupid solution whose only purpose was to make
> > the type field of the event structure uint16_t.
> I'm not sure how this is accomplishing this. Seems to me like a
> 16-bit integer is plenty big for a run-time URI registery.
Well, we are using 32-bit most everywhere else anyway, so even if that
were true it's still a problem.
However, since the scope of those URIs is really... well, all URIs (and
not just e.g. event types) I think 16 bits is pretty short-sighted. The
alignment sucks anyway.
> > The best thing, in the long run, would be to replace the event and
> > uri-map extensions to resolve this. Well, uri-map could be updated to
> > just deprecate the map parameter at least, but event has to go. That's
> > going to piss some people off and cause a lot of bad PR, though.
> I don't see why events depends on this.
The events have a type field which is a uint16_t integer mapped with the
> Deprecating the `map` parameter should be sufficient... even if you
> have to say "but for use with the events extension, you must pass the
> events extension URI as the `map` parameter" or some such thing.
That is exactly what the event extension says, and is exactly the
We need, in general, a method to map/unmap a URI to/from an integer. We
do *not* have this. We have a method to map a URI to/from a *pair* of
integers, i.e. we have several URI-integer namespaces.
The consequence of this is a big ugly mess of having to keep track of,
and convert between, contexts, and makes the whole thing much more
confusing than it should be.
While we're on the topic, using string interning instead is also an
option if we're going to change how we deal with URIs quickly. That
makes unmapping trivial... but pointers are not a fixed size across
More information about the Devel