[Devel] Atom Extension (was Re: Fwd: [RFC] URID extension)
d at drobilla.net
Sat Jul 23 14:22:56 PDT 2011
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
> > * 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
> > * 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?
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.
> 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", "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).
>  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.
More information about the Devel