Re: [liblo] getting reading for 0.28-rc

[Camille T. <ca...@os...>]

Alright Steve, sounds fine!
It's true that the cpp wrapper is just a header thus impacting the API only.


> On 28 nov. 2013, at 16:07, Stephen Sinclair <rad...@gm...> wrote:
> 
> On Wed, Nov 27, 2013 at 3:17 PM, Camille Troillard
> <ca...@os...> wrote:
>> 
>>> On 27 nov. 2013, at 15:01, Stephen Sinclair <rad...@gm...> wrote:
>>> 
>>> I pushed a proposed change to a github branch called "struct_types":
>>> 
>>> https://github.com/radarsat1/liblo/tree/struct_types
>>> 
>>> I think this is a positive change, but it could have implications for
>>> user code since technically it is an API change, although I believe it
>>> does not change the ABI.
>> 
>> I believe the same.
>> 
>> 
>>> I'm of two minds on whether to merge this.
>> 
>> Here is a suggestion:
>> 
>> I think we should focus on making the C code as free of bugs as possible.
>> 
>> Changing the type definitions will help go towards that goal, but it is risky to publish this change without making it well advertised to the users.
>> 
>> The new C++ wrapper helped identify an important weakness, but it is IMHO a bit too young to be distributed at this moment.
>> 
>> What about removing the C++ wrapper for this release (0.28) and extend the testing period with an RC2 release?
>> 
>> Then, we can peacefully think about the next release that includes the C++ wrapper and the better type definitions.
> 
> I will think about a way to get the C++ wrapper to work with
> ServerThread, or perhaps just remove ServerThread from it until it can
> be made safe.  However, I'd like to include the C++ wrapper in the
> release because I think it will never get enough testing without
> including it.  It should be safe to include because 1) no previous
> code could be using it since it is new, and 2) it is a header-only
> wrapper and therefore has no effect on the ABI.  I want to encourage
> people to use it early so that any API-breaking changes that are
> needed, if any, can be included in a new major-version of liblo.
> 
> That said, I'm fairly convinced that it is pretty safe, I have
> extensively tested it, including ensuring that memory is correctly
> tracked and freed.
> 
> As for changing the type definitions in lo_types.h, I will definitely
> not include this in 0.28, as it will certainly break existing code.  I
> have been compiling some reverse dependencies of liblo in Ubuntu and
> seeing errors in several packages.  Mainly (unfortunately) due to
> copy-pasting of the handler definitions in example_server.c where
> void* is used in place of lo_message.  (I'll change these.)
> 
> Probably it's time to start collecting API-breaking changes in a 1.0 fork.
> 
> In the meantime I'll keep testing against existing code that uses
> liblo.  (and binaries)
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel