Re: [liblo] lo_arg_size()

Hi,

On Sun, Sep 14, 2008 at 4:56 PM, Dave Griffiths <da...@pa...> wrote:
> Hi Steve,
>
>>> In version 0.25 of liblo, lo_arg_size() has gone. I can't find mention
>>> of it in the docs, any pointers?
>>
>> When adding the validation code, some of the internal functions were
>> moved to src/lo_internal.h.
>> This is mainly used for liblo to determine arguments for memcpy and
>> memory allocation.
>> Perhaps it shouldn't have been moved, though I'd be curious to know
>> how you're using it.
>
> It seems I'm using it in order to get the total size of a message's
> arguments in order to copy them from a message into a ring buffer - see
> DefaultHandler() here:
> http://cvs.savannah.gnu.org/viewvc/fluxus/fluxa/src/OSCServer.cpp?root=fluxus&view=markup
>
> It's ages since I wrote this, so there might be a better approach without
> using it...

Okay, after some thought it was probably a mistake to consider
lo_arg_size() as an internal function.  I can see it might be useful
in some cases to get the argument size, though admittedly it's a bit
weird since there are few cases where you'd need the argument size in
a type-generic way.  Even in your example you loop through the
arguments and do type-specific things, but for reserving memory in
advance it's clearly a useful function.

More useful for your situation though, I think it would be great to
have functions to help defer OSC messages or pass them around to other
threads for manual dispatch, storing them in a ringbuffer and then
removing them, for example.  Some thought on that subject would pay
off well I think.  I've personally had to modify liblo in the past to
allow me to pass off OSC messages for handling in another thread.  In
other words, an API layer treating OSC messages as raw memory that can
be passed around might be very handy.

I don't know how I managed to move this function without thinking
clearly about it, but there are a few other functions that got moved
into lo_internal.h that maybe shouldn't have:

lo_get_path()
lo_arg_host_endian()
lo_arg_network_endian()

They are all arguably internal: lo_get_path() isn't necessary in
message handlers since it is provided as a parameter, and the
endianness converters are used before messages are dispatched and thus
a bit unnecessary.

But I will probably move them back as well, just on the idea that it
breaks the published API.


Steve