liblo-devel Mailing List for LibLO

On Mon, December 11, 2017 16:14, Stephen Sinclair wrote:
> On Mon, Dec 11, 2017 at 11:25 AM, Thomas Brand <to...@tr...> wrote:
>
>>
>> Hi,
>>
>>
>> I'm wondering about your thoughts on the following proposal:
>>
>>
>> -Allow to serialise and deserialise messages with optional byte
>> swapping
>>
>> For instance adding a new method lo_serialise_message_swap with an
>> additional argument 'swap' that tells whether or not the message
>> arguments should be converted from host to network order. The existing
>> lo_serialise_message would then become a wrapper to call the new method
>>  with swap=1. The same for lo_deserialise_message.
>>
>> This would allow to create a close relationship of C structs layed out
>> like an OSC message and the methods from liblo to
>> de-/serialise/introspect such structs without byte swapping involved. A
>> pointer to a struct could be deserialised to an OSC message and vice
>> versa.
>
> I think I understand what you mean, not 100% sure.  I think I would
> simply call it lo_serialize_from_struct or something similar.
>
> It sounds a bit prone to error to me, since every user would be
> defining his own structs that are supposed to correspond with the OSC
> message layout if I understand you correctly, but perhaps that could be
> curbed with some good macro programming to verify that struct layout
> corresponds.
>

Yes, of course setting up the struct is a bit more work to make it
byte-compatible with an OSC message, the only obstacle is different
endianness.

> However, I am not sure how a switch for controlling byte swapping
> applies.  Either the struct is in network order or machine order, but it
> shouldn't be up to the user to turn that on and off.
>

For regular operation, a user would not want to fiddle with this. IMO it's
a benefit of the OSC spec that the format is clearly big endian (which is
equal to network byte order) and that the host endianness is considered
for forth and back conversions.
Taking control on the conversion allows for special cases. It's not the
idea to ever SEND a little-endian serialised message since that would
clearly break the spec.

> Perhaps you could lay out more descriptively an example of what you
> have in mind.

In a scenario, there is a struct in shared memory. A process that knows
the struct can easily and directly access the struct members, read and
change values very efficiently. In contrast to an OSC message, where it
isn't foreseen to change single values of already added arguments if I'm
not mistaken.

Now I thought it would be nice if we could say, the struct is effectively
an OSC message (with host (say little endian) encoding!). Any process not
aware of the struct can parse it with any OSC parser to know more about
it, derive types, byte-offsets etc. IFF parser can be instructed to keep
endianness.

I've attached a small example that should show how struct<->osc message
could be used with modified message.c, basically wrapping the byte
swapping with in if() in lo_[de]serialise_message.

The basic idea is to make a struct "discoverable" using a well-defined
markup while letting programs use the struct as normal. Not sure if that
makes any sense :)

>
> Steve
>
>
> -------------------------------------------------------------------------
> -----
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

On Mon, Dec 11, 2017 at 11:25 AM, Thomas Brand <to...@tr...> wrote:
>
> Hi,
>
> I'm wondering about your thoughts on the following proposal:
>
> -Allow to serialise and deserialise messages with optional byte swapping
>
> For instance adding a new method lo_serialise_message_swap with an
> additional argument 'swap' that tells whether or not the message arguments
> should be converted from host to network order. The existing
> lo_serialise_message would then become a wrapper to call the new method
> with swap=1. The same for lo_deserialise_message.
>
> This would allow to create a close relationship of C structs layed out
> like an OSC message and the methods from liblo to de-/serialise/introspect
> such structs without byte swapping involved. A pointer to a struct could
> be deserialised to an OSC message and vice versa.

I think I understand what you mean, not 100% sure.  I think I would
simply call it lo_serialize_from_struct or something similar.

It sounds a bit prone to error to me, since every user would be
defining his own structs that are supposed to correspond with the OSC
message layout if I understand you correctly, but perhaps that could
be curbed with some good macro programming to verify that struct
layout corresponds.

However, I am not sure how a switch for controlling byte swapping
applies.  Either the struct is in network order or machine order, but
it shouldn't be up to the user to turn that on and off.

Perhaps you could lay out more descriptively an example of what you
have in mind.

Steve

Hi,

I'm wondering about your thoughts on the following proposal:

-Allow to serialise and deserialise messages with optional byte swapping

For instance adding a new method lo_serialise_message_swap with an
additional argument 'swap' that tells whether or not the message arguments
should be converted from host to network order. The existing
lo_serialise_message would then become a wrapper to call the new method
with swap=1. The same for lo_deserialise_message.

This would allow to create a close relationship of C structs layed out
like an OSC message and the methods from liblo to de-/serialise/introspect
such structs without byte swapping involved. A pointer to a struct could
be deserialised to an OSC message and vice versa.

Greetings
Thomas