[LAD] "enhanced event port" LV2 extension proposal

[Lars Luthman]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20071128/1b0c0fc9/attachment.pgp>