liblo-devel Mailing List for LibLO

Apologies, I just noticed that I forgot to include github user
"ventosus" in the list of contributors. I don't know his name, but he
contributed significantly to the bundle-related code.

Steve

On Thu, May 23, 2013 at 11:37 AM, Stephen Sinclair <rad...@gm...> wrote:
> We are pleased to present stable release 0.27 of LibLo, the
> lightweight, easy to use implementation of the Open Sound Control
> protocol.
>
> Open Sound Control (OSC) is a protocol for communication among
> computers, sound synthesizers, and other multimedia devices that is
> designed for use over modern network transports.
>
> This is the first release in quite some time, and includes several
> major features and improvements since the 0.26 release, particularly
> related to bundles, multicast, and TCP support.  Features include:
>
> - Support for sending and receiving nested bundles, including
>   ref-counted memory handling for bundled messages.
> - Support for multicast in oscdump and oscsend tools.
> - Callbacks for bundle handling.
> - Select desired network interface for multicast.
> - Fix blocking semantics of lo_server_wait() / lo_server_recv().
> - Make inclusion of threading-related code optional.
> - Basic compilation script for Android.
> - Allow to optionally disable server dispatch queueing at runtime.
>   (In this case messages are dispatched immediately even if they are
>   timestamped for later.)
> - Support bidirectional use of TCP ports using lo_send_from().
> - Add SLIP protocol support for packetization when sending and
>   receiving with TCP.
> - Allow to enable the TCP_NODELAY flag on TCP sockets.
> - Support for specifying server parameters via URL string, and also
>   support for URL strings in the oscsend and oscdump tools.
> - As a result of the above, support for TCP and Unix sockets in the
>   oscsend and oscdump tools.
>
> Bug fixes include:
>
> - Fixed timestamp serialization.
> - Fixed blob padding and char-type padding.
> - Close sockets properly under Windows.
> - Fix multicast under Windows.
> - Fix TCP reception blocking behaviour, such that a message can span
>   multiple calls to recv().
> - Correct printing of blob bytes.
> - Only call getnameinfo() when requested.
>
> This release contains contributions by:
>
> - Camille Troillard
> - Hanspeter Portner
> - Jamie Bullock
> - Joseph Malloch
> - Pete Goodeve
> - rjvbertin
> - Mok Keith
> - David Robillard
> - John McFerran
> - Artem Baguinski
> - William Light
>
> Please download it at SourceForge:
> http://downloads.sourceforge.net/liblo/liblo-0.27.tar.gz
>
> Or read the online documentation:
> http://liblo.sourceforge.net
>
> The git repository can be found at the following mirrors:
>
> - git://liblo.git.sourceforge.net/gitroot/liblo/liblo
> - git://gitorious.org/liblo/mainline.git
> - https://github.com/radarsat1/liblo.git

Hi Steve,

Congrats on the 0.27 release!


On 22 mai 2013, at 19:38, Stephen Sinclair <rad...@gm...> wrote:

> Most of the flags are just booleans, I don't see any reason not to use flags?

It's fine, in my mind I has the impression there was more different options types, and/or you were trying to make the options system more flexible.  Since we are now using mere accessor it made sense to me to model the state in, for example, a packed structure of ints (which I find safer than a int as a bitfield), to make options more explicit.

I'll try to make a suggestion of what I had in mind, and apply it to lo_address as well; this won't change the API.


> The only one that is not just a local boolean is LO_NODELAY, which
> actually sets a socket option.

Yes, hence there is no real need to store that option in a variable, you can use getsockopt to retrieve the value of the option.


Best,
Cam

We are pleased to present stable release 0.27 of LibLo, the
lightweight, easy to use implementation of the Open Sound Control
protocol.

Open Sound Control (OSC) is a protocol for communication among
computers, sound synthesizers, and other multimedia devices that is
designed for use over modern network transports.

This is the first release in quite some time, and includes several
major features and improvements since the 0.26 release, particularly
related to bundles, multicast, and TCP support.  Features include:

- Support for sending and receiving nested bundles, including
  ref-counted memory handling for bundled messages.
- Support for multicast in oscdump and oscsend tools.
- Callbacks for bundle handling.
- Select desired network interface for multicast.
- Fix blocking semantics of lo_server_wait() / lo_server_recv().
- Make inclusion of threading-related code optional.
- Basic compilation script for Android.
- Allow to optionally disable server dispatch queueing at runtime.
  (In this case messages are dispatched immediately even if they are
  timestamped for later.)
- Support bidirectional use of TCP ports using lo_send_from().
- Add SLIP protocol support for packetization when sending and
  receiving with TCP.
- Allow to enable the TCP_NODELAY flag on TCP sockets.
- Support for specifying server parameters via URL string, and also
  support for URL strings in the oscsend and oscdump tools.
- As a result of the above, support for TCP and Unix sockets in the
  oscsend and oscdump tools.

Bug fixes include:

- Fixed timestamp serialization.
- Fixed blob padding and char-type padding.
- Close sockets properly under Windows.
- Fix multicast under Windows.
- Fix TCP reception blocking behaviour, such that a message can span
  multiple calls to recv().
- Correct printing of blob bytes.
- Only call getnameinfo() when requested.

This release contains contributions by:

- Camille Troillard
- Hanspeter Portner
- Jamie Bullock
- Joseph Malloch
- Pete Goodeve
- rjvbertin
- Mok Keith
- David Robillard
- John McFerran
- Artem Baguinski
- William Light

Please download it at SourceForge:
http://downloads.sourceforge.net/liblo/liblo-0.27.tar.gz

Or read the online documentation:
http://liblo.sourceforge.net

The git repository can be found at the following mirrors:

- git://liblo.git.sourceforge.net/gitroot/liblo/liblo
- git://gitorious.org/liblo/mainline.git
- https://github.com/radarsat1/liblo.git

Stephen Sinclair
  LibLo maintainer

On Tue, May 14, 2013 at 5:24 AM, Camille Troillard
<ca...@os...> wrote:
> Hello Steve,
>
>
> On 13 mai 2013, at 22:55, Stephen Sinclair <rad...@gm...> wrote:
>
>> Okay there is a proposal for explicit functions for each option on the
>> master branch.  It removes any mention of the "flags" operations from
>> the external API, however a "flags" variable is still used internally.
> Thanks for doing this!
> Just a question: why is a flag still used internally?
> I don't see how useful it can be compared to changing state directly from the accessors.

Most of the flags are just booleans, I don't see any reason not to use flags?

The only one that is not just a local boolean is LO_NODELAY, which
actually sets a socket option.

>> Also, I merged `nested_bundles' and fixed a few MSVC-related compilation errors.
>>
>> I think I am pretty much ready to release 0.27 if there are no further issues.
>
> I did not had problems with the latest networking code changes, so it seems 0.27 is almost ready.

Great!

Steve

Hello Steve,


On 13 mai 2013, at 22:55, Stephen Sinclair <rad...@gm...> wrote:

> Okay there is a proposal for explicit functions for each option on the
> master branch.  It removes any mention of the "flags" operations from
> the external API, however a "flags" variable is still used internally.

Thanks for doing this!
Just a question: why is a flag still used internally?
I don't see how useful it can be compared to changing state directly from the accessors.


> Also, I merged `nested_bundles' and fixed a few MSVC-related compilation errors.
> 
> I think I am pretty much ready to release 0.27 if there are no further issues.

I did not had problems with the latest networking code changes, so it seems 0.27 is almost ready.


Best,
Cam

Okay there is a proposal for explicit functions for each option on the
master branch.  It removes any mention of the "flags" operations from
the external API, however a "flags" variable is still used internally.

Also, I merged `nested_bundles' and fixed a few MSVC-related compilation errors.

I think I am pretty much ready to release 0.27 if there are no further issues.

Steve


On Tue, Apr 23, 2013 at 4:04 PM, Stephen Sinclair <rad...@gm...> wrote:
> On Tue, Apr 23, 2013 at 12:50 PM, Camille Troillard
> <ca...@os...> wrote:
>> Hi Steve!
>>
>> Sorry, I was overwhelmed lately.
>
> No problem :)  Sounds familiar.
>
>> After some thought, I am not sure if an option API is really needed.  Wouldn't an property based API (i.e. explicit accessors to properties of lo_address, lo_server) be enough?
>>
>> I understand the attractiveness of an "abstract options" API, but I wonder if it will really solve anything, other than hiding properties behind another interface.  I don't want to sound negative, I am just testing the opposite idea.  So here's another suggestion: get rid of the options enums and turn them into something explicit.
>>
>> On the other hand, the benefit of the abstract options approach is that it will keep the Liblo API from growing.  Only on the surface, as internally new options will need to be handled and checked anyways.
>>
>
> Yeah okay, I actually had the exact same concern which is why I wanted
> to bounce the idea around before committing to it.  I do admit that I
> find the API is getting a little out of hand, but at the same time
> having explicit functions for each option makes them easy to test for
> using autoconf.
>
> In principle it would be nice if all of these options (especially
> protocol selection such as SLIP) could be expressed in liblo's URL
> format.
>
> Steve