[Devel] Atom Extension (was Re: Fwd: [RFC] URID extension)

[Gabriel Beddingfield]

On 07/22/2011 02:14 PM, David Robillard wrote:
> 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:

OK, after reviewing it and thinking about it more... I like it.  I agree 
with you that we should drop the blobs/non-POD/reference stuff until 
someone actually wants to use/implement something.

>   * An "event" is simply an atom with a timestamp prepended to it
>
>   * A frame-timestamped buffer format ("EventBuffer")

Sounds like it duplicates the Event ext... except that the timestamp is 
type-limited.  I would prefer to deprecate the alternate timestamps in 
Event.  I don't think anyone uses that feature, and it makes it harder 
to implement plugins.

>   * An EventBufferPort type which covers the current use case of the
[snip]
>
>   * An AtomPort type which takes only a single Atom/Event and is mostly
[snip]

Good ideas... but perhaps they should wait until an application/plugin 
wants to use them?

> 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.

Your "Variant" suggestion was good... however, "Event" is already a 
Variant, isn't it?  So....

> Other thoughts on this general vision most welcome.  For an example of
> the practical use (and high priority) of this: this is what I see as the
> solution to e.g. UIs sending "load this file" messages to the plugin.

Right now, I tend to think of this extension as "A library of standard 
POD (Event) types."  I know it's not tied down to Events (and that's 
really cool) -- but that's still the idea.  So if we limit it to that 
kind of vision... I think it becomes extremely useful, easy to 
implement, flexible, and extensible.  (We can add more POD types later 
with 0 headaches or ABI issues.)

So with that in mind, I think something like "DataTypes", 
"EventTypes"[1], "MessageTypes", "Variant", or something along those lines.

-gabriel

[1] Yeah, strictly speaking "EventTypes" is a bad name because
     it puts a mental limit on the potential for these types...
     but on the other hand it's an easy-to-understand-immediately-
     what-it-does-for-me name.