2012/10/25 Stefano Di Martino <stefan...@gmx.net>: > I don't see a problem there. When someone uses openusb as backend, then > because it wants to use it and its features. > When someone uses libusb as backend, then because it wants to use it and > its features, and right there is pyUSB lacking right now.
I understand that. > You don't give > me the possibility to use my prefered lib in its full extend. I don't give because it is not implemented yet. > Like I > said: I could extend pyUSB and commit the changes if you want or I do my > own fork and the man power gets spread again, like it happend with > libusb and its 3,4 or 5 forks... Is latter an good option? I don't think > so... > The problem is how to make a backend specific feature available on final API and keeping it sane for users from other backends. I am still thinking in a good approach, the best I came is to provide specific modules, like usb.libusb, with features only available in libusb. One thing that I learned is to think careful about your API, because frequent API breakage is something that pissed users off... I asked about the use of that to have an idea if it is something urgent or not. Currently, I have more important features missing, like isochronous transfers, and I have to manage with my (currently short) free time. If you want to propose a solution, I am hearing, but I cannot promise when it will be integrated. That said, I think fragmentation is bad, but if you want to fork it, go ahead, freedom is what OSS is about :) -- Best Regards, Wander Lairson Costa ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ pyusb-users mailing list pyusb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyusb-users
