[LV2] messages and URIs

[Stefan Kersten]

On 03.03.12 06:39, David Robillard wrote:
> On Fri, 2012-03-02 at 12:31 +0100, Stefan Kersten wrote:
>> i think it would be good to have an architecture independent binary wire 
>> specification for LV2 atoms in order to be able to compare 
>> expressiveness and performance to OSC.
> 
> This could be done for the standard types anyway (but you couldn't
> guarantee it for all atoms in general).  It should be relatively
> straightforward to write a function that scans an atom recursively and
> switches the endianness of all the numbers to network order and back.

maybe it could be encoded in the stream so only the receiver needs to byteswap
(if at all)?

> Personally, I hadn't planned to care about that, because usually you
> have one of two situations: control from user interfaces and the like,
> where text is plenty fast enough, or IPC on a single machine for actual
> processing, where endianness doesn't matter.  Is there even a reasonable
> use case for an architecture-independent binary wire protocol?

well, ipc between multiple machines ;) i admit it's a special case, though,
outside the scope of LV2.

>>> Why do you need the myEngine:NodeId?  What other namespaces do you have
>>> for numeric IDs?  Another option could be to reserve the last few
>>> characters for a type so you can still distinguish type with a single
>>> numeric ID.
>>
>> there are at currently four id namespaces, for nodes, control and audio 
>> buses and buffers.
>>
>> i could use different base URIs, e.g.
>>
>> urn:myengine/node#12345
>> urn:myengine/audioBus#12345
>> urn:myengine/controlBus#12345
>> urn:myengine/buffer#12345
>>
>> but this seems wasteful in terms of bandwidth and memory allocator 
>> pressure (mainly for nodes, the other resources are generally more 
>> persistent). i think the most efficient option would be to encode the 
>> type in the id, but it seems like a hack ... now that i think of it, the 
>> type doesn't really need to be transported; if every resource knows how 
>> to handle a message, i just need one big map of URI/URID to resource.
> 
> Yeah, I think you really want to make all these things use a single
> namespace, regardless of whether its numeric or string.  Your problem
> isn't really LV2 atom specific, it's that you don't have proper IDs for
> things you want to talk about.  That never ends well.

the ids are quite proper, they just don't fit into the message extension's
notion of "every object has the same interface". i'll need to redesign a little.

> If your performance needs are that high, I don't see any real
> alternative to a single number.  The blank node description in your
> original email is over 30 bytes in binary format, those headers add up.

yep, an integer id is the way to go.

<sk>