On Wed, 2007-11-28 at 15:56 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
> > I guess my point was that I think this should be part of the semantics
> > of the particular event type that needs it.
>
> Well, making the common part common (for all "large" events) doesn't
> hurt. And it can potentially make stuff easier for transparent bridging
> over the network (when each "large" type implements an interface for
> serialization/deserialization).
Sure, but you don't need it to be defined in the event transport
specification itself. There's nothing that says that different
lv2:Features (event types in this case) can't share code and binary
interfaces - the IDataBuffer could be defined in a separate file that is
not part of the actual event transport extension but used by all event
types that need it. Even if a simple host that only wants to deal with
MIDI can completely ignore the IDataBuffer part of the event transport
specification it still makes it _look_ more complicated and adds
potential confusion - I think it's better to have it outside the basic
event spec.
> ...
>
> Serialization is necessary because "large" events can potentially refer
> to some "foreign" objects, like handles to OpenGL textures in video
> memory and what not :) You cannot assume that all of your "large" event
> data will be conveniently placed in a single contiguous buffer in RAM,
> because it might not be the most practical way of dealing with them.
No argument with any of this. Passing around reference counted opaque
objects can certainly be useful and I can imagine lots of sexy
applications, I just don't think it needs to be in the event transport
specification when it works just as well outside it.
--ll
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
This archive was generated by hypermail 2.1.8 : Wed Nov 28 2007 - 20:15:07 EET