[Devel] Fwd: [RFC] URID extension

[David Robillard]

On Fri, 2011-07-22 at 16:36 -0500, Gabriel M. Beddingfield wrote:
> 
> On Fri, 22 Jul 2011, David Robillard wrote:
> 
> > On a related note:
> >
> > The real sticking point here is the event extension.  URI map doesn't
> > actually *have* to go, but might as well do it cleanly to eliminate
> > confusion (at the cost of temporary hassle).
> 
> uri-map can be implemented by urid.  In every uri-map 
> implementation I've seen, this will be no big deal at all... 
> because they're returning static values.

Well, yeah.  There's not really any concrete reason to replace uri-map
at all, other than to remove the map parameter.  The urid extension
should be explicitly equivalent to uri-map with map = NULL anyway...

A static map is not really an acceptable implementation.

> > My vision for this is basically the existing "atom" extension with a few
> > minor additions to make it take on the former job of the event extension
> > as well:
> 
> Is this the same as http://lv2plug.in/ns/ext/atom in SVN? 
> If so, I'll inspect that before making any comments.
> 
> I noticed that it also has a uint16_t `type`.  Didn't you 
> point to this as the major failing of the Event extension?

Yes.  This is the problem.  It is this way to be compatible, every event
contains an atom, so you can "convert" in place.

> > Simple silly question: any opinions on the name for this?  Is "atom"
> > good?  "Object" would seem natural as well, but it clashes with RDF
> > "object".  "Blob" implies complete untypedness which is undesirable.
> 
> FWIW, in X11 what they call "Atom" is more or less what LV2 
> calls "urid" or "uri-map."

The term used here probably inherits from LISP more than anything.

Personally I don't think the clash with X11 is that big of a deal, but
no clash at all would be nice.  Other ideas are "value" or "variant" or
"node".

-dr