On 12/04/13 00:27, Pete Batard wrote: > On 2013.04.11 16:20, Toby Gray wrote: >> Rather than trying to optimise how the fake fds are generated and >> handled, I think the best thing to do is to add improved APIs to improve >> event handling on platforms which don't have fds and then change the >> internals to not need fake fds. > Oh boy, here we go again...
Sorry, I didn't realise it was a common discussion point. I was trying to avoid doing what I did with the WinCE backend of going ahead and implementing something and only talking to the community when it was done. I think the summary from all the replies seems to be: * any changes to event handling will not be considered for merging until after hotplug is done (at least 10 months time) * any work on event handling is likely to be unusable once hotplug starts to be implemented (as it is likely to also modify event handling code) * if I'm contributing time to libusbx development that it would be more useful if it was working on hotplug (or other features in the next milestone) * don't send apis, send working code :) >> Before I rush off an implement something, I wanted to check with the >> community to see how people feel things should be done. > If that's the case, then you may want to check 3 years of libusb mailing > list archives as well as one year of libusbx, because this topic has > probably been discussed about once every 3 months on each list. > > I think the plan on which we more or less agreed for libusbx was that we > would wait until _AFTER_ we had an initial hotplug implementation for > all of Linux, OS X and Windows, to look into improved event handling. > > The reason is it'd be nice if the hotplug event handling could fit with > the transfer event handling, but until we see clearer in terms of > hotplug, whatever we _think_ we need in terms of event handling may end > up being way off mark. > > Also see the current v2.3 libusbx milestone: > https://github.com/libusbx/libusbx/issues/milestones > > IMO this is still way off on the horizon, and isn't something we should > be looking at right now, especially not in the 1.x branch. All of which are very understandable and good reasons. I am still (pleasantly) surprised that the WinCE backend was integrated so quickly. I was expecting at least a year of maintaining it in a branch until a suitable milestone came up. I have the same, original, expectations of needing to maintain a branch for 12+ months for any patches that I come up with for improving the event handling performance. > OK, then let me be very frank here (with an opinion that'll probably not > reflect the one from other libusbx maintainers): I'm getting kind of > tired of people proposing yet another API, without any details of how > it's actually going to be implemented for each of our 3 major platforms > (Linux + OS X + Windows). And yeah, I know RFC and whatnot may sound > like the way to go, but proposing an API _is_ cheap, and, judging from > our mailing list history, seems to be a sure way to generate a lot of > discussion that ends up nowhere or worse, that detracts people from what > our real number one need which is: code, code, and more code. Frankness is good and gets across the point. Unless some else posts something that I feel I really need to reply to, I don't plan on sending any more traffic to the mailing list about this until I have a working implementation (for all backends) with useful performance figures. I especially appreciate that you've taken the time to write a long reply, but that the time you spent writing the reply could have been spent making libusbx more awesome. <snip> > So if it were up to me, I'd try to concretely find out what we really > need (which, unfortunately, requires a somewhat working Windows hotplug > implementation) before trying to introduce improved event handling... To return your frankness: the majority of my time spent on libusbx is as part of my day job. That means that it is difficult to justify using company time to implement features that aren't of any direct use to the company. The libusbx activity I can do when not at work is limited by lack of non-free development tools and environments at home. We are happy to accept that our requirements won't match up exactly with the requirements of the libusbx community and so we might need to maintain a branch of libusbx with bug fixes and functionality that we need for months, if not forever (but hopefully not). In this case though I've clearly let the community know a bit too early and wasted everyone's time. As I mentioned above I'll wait until I've got working code with a measurable benefit before bringing this subject up on the list again. Regards, Toby ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
