Hi Richard, I guess I'll bite, and fill you in on a few details, to try to offer a different perspective from what you seem to _perceive_.
The first thing you need to realize is that we're not Apple or Microsoft here, or can rely on people people living off of a retirement fund ,with the luxury of being able to contribute code for libusbx all day long. No matter where it is conducted, software development IS a costly activity, either in time or money, and a FLOSS project has to pick up that cost from somewhere. What that means to you is that people involved on a project don't exactly get to spend every other hour of their limited free time carrying out work for it, especially as most won't usually restrict themselves to a single project. Ergo, the time people can invest on a daily or weekly basis on something such as libusbx is a more limited than outsiders tend to imagine. The implication then is that prioritization needs to occurs with regards to features and bugs, and some stuff gets delayed or falls by the wayside. Then again, since the amount of work we can accomplish is directly proportional to the number of contributors willing to invest some of their spare time with the project, you're more than welcome to help us, by proposing patches that we can integrate. On 2013.03.12 16:52, Richard Hughes wrote: >>> * libusb_resetep >> Not implemented yet. >> Ref: https://github.com/libusbx/libusbx/issues/18 > > Seems no-one is interested. :( Not really. As highlighted above, not having a chance to dedicate time working on an issue doesn't mean we aren't interested. It's just that, in the limited time we can invest on the project, other fixes and features may take precedence. >>> * libusb_handle_events_check >> This is probably an extension by Graeme. > > Seems to be discussed in http://www.libusb.org/ticket/56 Seems to be closed. And it seems the patch was rejected by the libusb maintainer on account of looking for a better name for the call. >>> * libusb_strerror >> Not implemented yet. >> Ref: https://github.com/libusbx/libusbx/issues/14 >> Graeme was using an older implemetation which >> was not accepted into libusb-1.0 or libusbx. > > Surely this is a no-brainer to add such a simple thing to libusbx? Then congratulations on reopening this can of worm! There's a bit more than meets the eye there so let me brief you on that story. 1. I had libusb_strerror() (which was proposed by someone else) in my libusb branch, about 2-3 years ago. 2. It got integrated into libusb for some time, and this is where Graeme picked it up when he forked his own version of libusb (or it might still have been my branch but it doesn't matter). 3. After a while, the libusb maintainer decided that he didn't like this call and wanted something better, that supported internationalization, so he removed it [1] (hence your issue, since Graeme hasn't been interested in following either of libusb or libusbx after his fork) 4. We've been wanting to add libusb_strerror() back to libusbx pretty much as soon as we forked (1 year ago), but a few people on our also list supported the idea of adding internationalization while we were at it. 5. I remember spending quite some time trying to get the advocated method for internationalization working on Windows, so that we could ease up the maintenance, but unfortunately we ended up finding that it created a headache. During that time, some of the people who supported a full fledged approach to internationalization left libusbx. 6. After a few months, and if I recall correctly, we decided that we'd try to pick up the libusb_strerror() integration, but with simpler internationalization handling. 7. Ever since, and since it shouldn't to take too long (though it's not a 5 mins job either), I've been trying to find the time to do it. However, I don't consider it high priority enough to justify displacing other activities that also needed to happen with regards to libusbx. As to why we don't just revert to the non internationalized libusb_strerror() and then add a new parameter for internationalization later, it'd mean API breakage which some of our users are sure to find objection with. As to why we don't just revert to a non internationalized libusb_strerror() and keep it that way, the consensus at this stage is that we do want to have an internationalized version, and it shouldn't require that much extra work to achieve that. Now, I would say that your issue, really, is that you're taking a version of libusb that was never official or affiliated to libusb, with APIs that were never approved by the libusb maintainer or removed, and trying to make it work with the regular up to date version of libusb/libusbx. Unfortunately, when software doesn't update its dependencies on a timely basis, breakage can and does occur. > Shouldn't this trigger some kind of alarm in the libusbx project? I > mean, if users like Graeme are dropping libusb for something > hand-rolled because it's not suitable, what's the point in libusbx? As far as I could see, but this is just my personal opinion, Graeme doesn't like to have to spend more time than he thinks he should spend to keep external code up to date or trying to follow the practices other projects may expect from contributors (such as creating and maintaining your own git branch when proposing a major patch, maintain/support your code and take into consideration improvement requests). Using either of libusb or libusbx, or any other library for that matter, would meant he'd have had to invest time doing just that. Now, if you think that's too much of a burden/time waster, then the easiest way to avoid it is just remove your dependencies, which is what Graeme decided to do in the end. Also, you may want to consider that most of the people on this list also dropped libusb when we decided to create our fork, partly on account that we didn't like to see its maintainer deciding to remove valuable function calls, or ignoring patches. We're trying to do a better job, but, yeah, that requires patience from our users. That is, unless they are willing to contribute on the features/fixes they want... Regards, /Pete [1] http://git.libusb.org/?p=libusb.git;a=commit;h=4be84ab49c838d534d3a1b8a64ffa89774984ee7;js=1 ------------------------------------------------------------------------------ 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_d2d_mar _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
