[LAD] "enhanced event port" LV2 extension proposal

[Krzysztof Foltman]

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