[Devel] Atom Extension (was Re: Fwd: [RFC] URID extension)
gabrbedd at gmail.com
Sat Jul 23 14:02:26 PDT 2011
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
> * An AtomPort type which takes only a single Atom/Event and is mostly
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", "MessageTypes", "Variant", or something along those lines.
 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-
More information about the Devel