[LAD] "enhanced event port" LV2 extension proposal
wdev at foltman.com
Wed Nov 28 16:45:09 UTC 2007
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.
- simpler and shorter specification
- 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
More information about the Linux-audio-dev