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

[David Robillard]

On Sat, 2011-07-23 at 16:02 -0500, Gabriel Beddingfield wrote:
> 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.

Moved to a new "reference" extension.  Nomenclature probably needs
revision.

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

Replacing event is indeed the idea.

> >   * 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?

Hm?  Obviously applications use event buffers!

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

Event implies time, variant is more general.  Variant is the more
correct term, it's just a big more verbose.  I suppose I can let go of
my rabid desire for brevity and use it :)

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

Right.

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

Right, and types can be added by other extensions or even used in a
completely laissez-faire way.

Replacing the event extension to be compatible with and/or included in
and/or based on the atom extension still needs to be done though.  It
can be done in this extension itself, or in a different one.  The main
problem with doing it in a separate one is we'll need to name it, and
event-2 is ugly :)

Though, that said, maybe we should just get on with being okay with
sticking numbers on the end anyway.  The new UI extension is called
"pui" to avoid this... it's getting a bit strained.

> So with that in mind, I think something like "DataTypes", 
> "EventTypes"[1], "MessageTypes"

Not a fan, we need an established proper noun for these things.

> , "Variant", or something along those lines.

Best one so far, IMO, and well established (in programming language
terminology, glib, etc).  I guess I'll just rename atom to variant
(though "atom" isn't so bad, really).

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

"Event" is not an acceptable name for these more generic things.

-dr