3 Feb 2008 20:23
Re: 1.0 API?
Paul Klissner <Paul.Klissner <at> Sun.COM>
2008-02-03 19:23:52 GMT
2008-02-03 19:23:52 GMT
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/