Dave Robillard wrote:
IP doesn't dictate packet contents whatsoever. It
does what it needs to
do quite well, I don't think it's crufy at all. It would be crufty if
it tried to define, say HTTP error codes...
That's right. Lars addressed that criticism pretty well, I think. The
"evolved" proposal is both keeping headers and data in the same place
and keeping event semantics on separate layer from event transport.
Please look at the definition of the LV2_MIDI struct
in lv2-midiport.h.
Note the char* parameter, and read it's comment. The buffer is flat,
there is no cache thrashing or any such issues here whatsoever.
Here it comes:
char* buf; ///< raw event data
Maybe you meant to write this?
char buf[]; ///< raw event data directly follow here
Because char* usually means, you know, a pointer, not a variable length
array :)
Take this, and solve alignment and URI numbering issues, and both
proposals (LarsL&KF and yours) are actually the same one. Which is a
good thing.
The only problem that needs to be handled is how to
get the type in
there. I would like to find a good solution to this problem that's as
extensible as URIs but doesn't actually stick a URI in the event struct
(there are a few other future extensions that have the same problem.
Lars solved that one pretty well.
strcmp of URIs in the audio thread is, as you say,
completely out of the
question, but so is handing out a flat numeric space.
Unless the handing out is done on the fly, based on URIs. Like, say,
file descriptors :) We still have "central authority", but this time
it's the host loading the plugins, not a person. Should give a much
better roundtrip and less authority abuse ;)
Krzysztof