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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev