Lars Luthman wrote:
Sure, but you don't need it to be defined in the
event transport
specification itself.
I think that might work. But then, you can only pass object pointer
events that are known to the recipient. Especially in plugin-to-host
direction (because with host-to-plugins, the host can just decref any
object used in an event after plugin's process function ends, no big deal).
This assumption is acceptable, in my opinion.
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.
Advantages:
- simpler and shorter specification
- modularity
Disadvantages:
- you can't tell between an object pointer (which cannot be just copied
over the network or between processes) and normal data (which can be
copied freely); at least not using this specification alone
As long as some additional specification for passing object pointers in
events follows this specification (some day), I'm fine with it.
There is also a possible middle ground - an event type declaration in
rdf would say not just what URI it corresponds to, but also if it
contains any "unsafe" data (like pointers, handles etc).
Just to possibly prevent a hypothetical transparent network/interprocess
bridge from trying to smuggle pointers between process boundaries, which
could lead to unexplained crashes :)
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.
Good. So let's postpone that part for now, it will go into different
extension(s).
Krzysztof