Hi Jim,
On Monday, 18. June 2012 20:32:52 Jim Paris wrote:
> What APIs were broken between libftdi-0.x and libftdi-1.x? Can they
> be fixed? Even if not, we should strive to maintain compatibility in
> the future so we don't just run into this problem again. For example,
> adding a version or size field to struct ftdi_context would let us
> determine in the library which API the binary was compiled against.
> For functions with a changed implementation, the old implementation
> should be maintained as-is or with a compatibility shim, and the new
> implemtation should be given a new name.
Thanks for your feedback. There are multiple things that will break
backward compatibility in the binary data structures:
- We expose variables. So far nobody had time
to provide set/get functions.
I also don't want to delay a libftdi 1.0 release because of this.
It's already painful that two library versions are actively used.
- We expose the raw libusb device. This structure will certainly change
when upgrading from libusb 0.x to libusb 1.x :)
- (Experimental) async API is totally different
> Ulrich Drepper's Good Practices in library design, implementation, and
> maintenance: http://www.akkadia.org/drepper/goodpractice.pdf
> Ulrich Drepper's How to write shared libraries:
> http://www.akkadia.org/drepper/dsohowto.pdf
> Mike Hearn's Writing shared libraries:
> http://plan99.net/~mike/writing-shared-libraries.html
>
> With the right design and care on the library end, the API can be made
> stable enough that a user application can simply include the system's
> single /usr/include/ftdi.h and be confident that the code will still
> continue to compile and run correctly even if a new version of libftdi
> is installed.
Thanks for sharing the links, quite a good read. Might be an option
for the future, if anybody provides patches for this :)
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
