28 Nov
2007
28 Nov
'07
12:20 p.m.
On Wed, 2007-11-28 at 15:56 +0000, Krzysztof Foltman wrote:
Lars Luthman wrote:
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.
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). ...
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