On 12 March 2013 22:42, Pete Batard <p...@akeo.ie> wrote: > 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_.
Sure, it was meant somewhat tongue-in-cheek, so I appreciate the response. I'm not deliberately trolling. > 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. >From my (perhaps naive) point of view, it seems much more priority is being given to edge features like WinCE support, rather than core issues with the library. >> Surely this is a no-brainer to add such a simple thing to libusbx? > 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. That seems a strange way of doing it. Surely adding the non-localised method first is the best way, then perhaps localizing the Linux version, and the other OS's is there is demand. I'm also slightly sceptical that strerror *needs* to be localised at all, as surely we don't want those errors presented in any kind of UI. > 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. I maintain lots of libraries myself, and I really don't agree. It's perfectly fine to *add* API later for different use cases. It's find to have both libusb_strerror() and libusb_strerror_with_locale(char *locale) or libusb_strerror_full(char *locale), or even just use libusb_strerror() and use the LOCALE env variable. It's impossible to design every method to be 100% future-proof, and more important to get something that works rather than delaying so that a method can cover every use-case. >> 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. I think the main issue is that he can't actually make his driver code work correctly without things like libusb_handle_events_check (which makes sense to me) and also libusb_resetep (which also makes sense for me on Linux). > 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... I'm perfectly willing and able to help and add the required methods, but I'm not going to be able to test or make the code work on any version of Windows or OSX, and that seems to a be a prerequisite at the moment. Richard. ------------------------------------------------------------------------------ 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
