Re: 1.0 API?

virtual_worlds <at> gmx.de wrote:
>> For example, at Sun, we'd prefer to not have to support libusb 0.1.x 
>> because we've implemented the API and experienced it's shortcomings 
>> in the bigger picture, and these shortcomings cannot be addressed 
>> in libusb 0.1.x as designed.
>>     
>
> I remember a partially similar situation with the libupnp: there development has more or less stopped
with version 1.2 and with support of only some operating systems. Beginning from that a fork was done to a
project "pupnp" (Portable libupnp) that brought the lib back to life: now it has reached version 1.6.x,
the API is fully compatible to the old one and it supports more operating systems and features than ever.
And of course all important distributions now use it instead the old one...
>   
Unfortunately backward compatibility is impossible.  Fundamental design 
limitations conflict
with evolutionary solutions to insidious problems.   For example, the 
library cannot both
simultaneously return as pointers to the internal implementation's 
structs, which applications
access directly though handles, and return handles that enforce MT 
safety.  Any attempt to
fix that will break bus enumeration for pre-libusb 1.0 compliant 
applications.  That's the
conclusion everyone who has tried to fix libusb 0.1.x has reached so far.

There are other cases too that can't be be simply painted over or built 
around in a
backward-compatible way.  I would need to re-investigate it again to 
cite more examples;
as it's been awhile since Johannes and I worked together to design the 
early libusb 1.0
architecture (which eventually evolved into OpenUSB 1.0).

> For me it sounds like that would be the best what could happen to libusb at the moment - the API would stay
untouched, applications that are using it currently would not be forced to change or to be modified and the
development could continue...
>   
libusb 0.1.x was made available prematurely, emerging more as prototype 
than product.
That had the inopportune consequence of stunting it's growth.   It's a 
dead end.  It doesn't
behoove a forward-looking application that may require flexibility and 
more sophisticated
USB usage in the future to pin it's hopes on libusb 0.1.x.

Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/