I'm sorry, but I don't get why we seem so hell bent (as it looks to me) on finalizing the API down to its last minute detail, when we still haven't really figured out how it's going to be implemented across the major platforms, an more importantly, what that's really gonna mean for our users.
We're not the USB committee. We're not in the process of releasing a new standard to the world with little margin for error. So could we please dial down the "we should make it perfect from the get-go" fallacy, when, regardless of what libusb decides to do, we can slap a big EXPERIMENTAL on our HP API for a few iterations and get actual user feedback? Or are we so arrogant that we think we can figure the whole thing by ourselves, without the need for real-life implementation reports? Now, that's not to say that the process of trying to devise what we we *think* our users will want from an hotplug API is a waste of time, in fact that's where we want to start. But the way this discussion has extended into the minutia of trying to finalize what names we should use for driverless device handling, when we still haven't a clue (or at least I don't) how we're going to implement this whole lot on Windows, and whether it'll result in something that's workable for our users, makes we wonder if we're not pushing this whole process a bit too far. Unless an API ends up as a code proposal that can be tested, and that can generate feedback from as many users as possible (which, IMO, is better done through actual releases that include experimental features, rather than RCs), I don't think it should be tagged or even remotely considered as "final", and we probably should try to keep some room for some potentially drastic changes. What's more, we're building a library, with developers as a target audience. So I would expect any developer starting to use a really brand new feature to have room to modify their code if the API evolves at short notice. And maybe some of you here feel that libusbx should be tied to the libusb API, but I don't see much point in participating in a fork if we can't go in our separate direction should we think it'll help our users better, especially if the reason for a deviation is users reporting that a first proposal doesn't work that well for them. And yeah, this means that our users may eventually have to choose between two incompatible APIs and non interchangeable libraries, but that's really the essence of forks (and that's alos why I believe we should only introduce hp in 2.x of libusbx to alleviate the problem). So, to get back to the current point, in case you ask me right now what kind of cross-platform API we should go with for hotplug and whether we want to go with DRIVERLESS_WHATEVER events, I'll continue to state "I don't know". And I'm not gonna know until I have a proposal with some Windows code, alongside the Linux and OS X one, that we can place in the end of our users, so that we finally start to receive feedback. Then again, I'm not going to prevent anybody from knocking themselves out with elaborating on what they think should go in a final HP API. Regards, /Pete ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
