On 2013.03.13 07:07, Richard Hughes wrote: >>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.
Glad you make that point, as it'll give me an opportunity to explain a few things. First of all, and if there's just one element that one should pick up from this lengthy blurb that'll be it: someone who asks for a feature and provides a patch will always get preferential treatment over someone who just requests a feature. _ALWAYS_. A good illustration of this would actually be the recent addon of FX3 support for the fxload sample. We've had that feature request open for months, but when someone came along with a patch, it got integrated in a matter of hours. So when Toby came to us in summer of 2012 with a proposal for WinCE support, along with a patch, then his work immediately became important to us as it offered us the ability to reach out to WinCE users with minimal effort (That's not to say that Toby's effort itself was minimal, but from our perspective, we had just been handed over a gift). And if you can bear with ill conceived analogies, as far as WinCE is concerned, it's a bit as if we were unexpectedly given a PS2. Sure the PS3 is the console of the moment, and the PS4 is just around the corner, but I'll be darned if we're not gonna say "Thank you very much" and try to find out if there isn't some "good game" to be gotten out of it (i.e. something that will be helpful for our users) still. Moreover, with our list being open to anyone, the 6 months or so it took us to actually get WinCE integrated left plenty of time for anybody to comment on whether they felt it made sense for us to spend time on that effort. Now, let's talk about these 6 months, because what really happened during that time, in terms of taking advantage of the very nice patch that got handed to us was... nothing. If you look at the mailing list, you'll see that the only thing that occurred during that time was me, dangling an ever delayed promise of integration to Toby, and even asking him to invest some more effort reworking parts of his solution, but with nothing happening (which was mostly due to lack of time from my side as well as stuff of higher priority occurring). Well, I don't know about you, but when you keep promising something for months, there comes a stage where you have to get your act together. So, yeah, _eventually_, the unofficial priority of the WinCE integration got bumped. Yet, I'm pretty sure that if you ask Toby whether he feels that WinCE has been receiving a somewhat preferential treatment, or was considered by us as high priority, he'll probably have a somewhat different opinion from yours. Finally, in case the recent WinCE cleanup work is only what you had in mind, please bear in mind that integration of a large piece of work always includes some post-integration housekeeping. There is a minimal effort that has to be directed to keeping a code repository that is easy enough for others to work with, as well as maintaining. Then again, if you really want to put an actual figure on how prioritized WinCE actually was from my side, and even counting the cleanup aspect, I don't think I invested more than 5 evenings in WinCE... over the course of these 6 months. Therefore I personally don't feel that WinCE got prioritized at all, or has diverted much of any resources away from other libusbx efforts. > 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. How about pushing that reasoning to its logical end then: Do we really need strerror? By all accounts, it could be considered as a superfluous function. Besides, is there really a scenario where argyllcms can't be modified to work without it? In a nutshell, strerror not being seen has priority material is really the reason not much has happened on that front and we've been taking our sweet time (and for the other call, we have enough to worry about not to go around reopening old issues that libusb closed, whether libusb was right in closing them or not) What's more, if we are only going to consider priority, and index it on what our users request, we should probably drop everything else (including releasing 1.0.15) and devote all of our time to hotplug. This has been our #1 feature request for years (that we got another request for that today is no exactly a coincidence). > 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. See above. Why should we multiply calls, and spend additional time on duplicated calls, when we can get a single libusb_strerror that'll work for both localized and non localized? No duplicates of documentation (because you can factorize code alright, but not so much documentation), no libusbx users having to pick between similar calls and potentially diverting resources by being confused and asking on the mailing list. There's always quite a bit more to just dropping some code and considering it done... (Oh and for the record, I believe using the LOCALE variable is something we tested on Windows, and it was problematic. Plus don't forget we are a cross-platfom library => whenever possible, we want something that'll work for all platforms --which has nothing to do with future proofing) As to whether it really needs to be localized, I'm actually on the fence on that one. However, some people strongly feel it should be and it's the job of a maintainer to try to satisfy requests, especially as providing a localized call will not detract people who don't care about localization from using that function anyway, so there's no reason to try to keep both sides happy. > 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. As Xiaofan pointed out, no problem with that. Any patch is welcome and makes the feature you want more likely to be added on a (relatively) timely basis. Regards, /Pete PS: Feel free to point out how I should probably have devoted the time I spent on this reply working on libusbx features and improvements instead. Regardless of prioritization, I still hope I have a minimal amount of choice on where I decide to direct my free time... ;) ------------------------------------------------------------------------------ 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
