On 2012.09.28 08:49, Hans de Goede wrote:
> Most work for distros with multiple ABI/API versions will be in that
> a parallel installable package for the new API/ABI will count as a new
> package, needing to go through various distro procedures for new packages,
> and once in place, there will be 2 (or 3 or 4) libusb library packages to
> maintain instead of 1.
Yeah. That's how libraries evolve, especially when:
1. We consider that deviating from the specs is something that warrants
immediate fixing
2. We are not allowed to fix even the smallest one-of errata without
bumping the API
Also, figuring things out without actually doing them is really really
hard, and personally I'd rather inconvenience people by providing them
with a couple API increments that don't rely on guesses, than risk
penalizing them with an ill-devised API .
If it reassures you, I don't want to have to go through more than 2
iterations of the API for the foreseeable future. However, it's hard to
promise that API course corrections can be evenly distributed as to keep
everybody happy.
I'm also a bit concerned at package maintainers feeling entitled to ask
software packages not to evolve, be it a library or not, when they have
the all too obvious choice to drop whatever they don't like (all the
more if it's a fork!). It wouldn't be the first time distro maintainer
make the choice of what they want to go with, if they feel that it can
reduce their workload and/or provide a better user experience. That's
also why I think we should have a bit of leeway in libusbx, should we
require it.
> This is all not necessarily disastrous :) But still
> we should at least try not to burn through ABI/API incompatible releases
> too soon.
Yeah, that's what I want too. But I really can't say for sure what we're
going to need from cross-platform hp until we actually do it. There are
still some elements on Windows, such as getting notifications for
"driverless" devices that can be linked to libusb(x) devices that may
very well derail our planned implementation. But figuring these may not
happen for another year or more whereas we have important enough API
changes lined up.
But since we're talking hp, and as promised, below is the breakdown of
the plan we laboriously came to devise for hotplug implementation
(around 2012.02.03):
1. hotplug that doesn't rely on cross platform event handling (eg. using
callbacks)/single-threaded hotplug
2. cross platform event handling and hotplug refactoring for multi-threaded
3. filter/enum overhaul and additional hotplug refactoring
At the moment, I don't exactly see us having a clear path on how to
implement 3 with the API for at least another year. I have some ideas of
course, but without a working prototype, I'd rather not vouch for any
related API changes.
> I also know of several upstreams for other libs who have done
> that and they are not popular with distros at all!
The great thing with being a fork is we can afford being unpopular: our
users have exceedingly easy means to switch away from us if they aren't
happy. :)
> I never was against that other then for compatibility reasons, so if
> we drop compatibility, lets rebrand :)
I wouldn't call a simple library name change and rebrand... If we're
going to rebrand the library name, I fail to see why we wouldn't
logically rebrand the include as well. For all we know, someone might
end up looking at the wrong library when they experience an issue with
an app they didn't develop, based on the header they see being used in
the source.
> My main worry here is packages which want to be able to build with
> both libusb versions.
And why on earth would we ever want to support that post 1.0, especially
when what prompted our fork is libusb's unability to release (and hence
a low expectation of packages ever being in a position to compile with
either libusb-2.0 and libusbx-2.0 at the same time).
But let me also ask you this: do you expect that libusb is going to go
out of its way to support buidling with both library versions?
Say we decide to go with libusbx.h for 2.0 API, and, about a year or two
after us libusb releases its own 2.0. Are you going to ask libusb to
consider changing their header to libusbx.h for 2.0, so that packages
that are have already been using libusbx 2.0 for some time, and want to
be able to use both have an easier time?
If not, then why should the reverse be true?
Also, here's my worry: we make the use of libusb or libusbx so
interchangeable that people start to think that libusbx's primary goal
is to make their app work just the same with two completely
_independent_ libraries. And then, one day, libusb suddenly decides to
reuse one of the API additions we have, in an incompatible manner, and
releases that before we have a say. A this stage, because of the
perception that libusbx should docilely follow what libusb does, we have
to spend spend time which we could use elsewhere fixing our API. Even
better, because of the implied promise above, we are the ones who get
blamed for breaking compatibility.
Oh wait, that's not a worry, this is what actually happened, no less
than 24 hours after our very first release, as libusb decided to release
without RC ans mess up the version structure we introduced. As to us
taking the blame for that breakage, that happened again less than a week
ago [1].
IMO, we have to make it as clear as possible that a fork does require a
conscious decision to use either library from our users, and that our
duty stops at making transition/evaluation process (back or forth) as
simple as possible. But past that initial transition process, I don't
see it as our best interest to make toggling between libusb and libusbx
so easy that the perception will be that switching back and forth every
other day is something we're gonna spend time on. This is all the more
true when forked libraries start to deviate at the API level, which is
exactly what we're discussing here. Let's do everybody a favour and
produce a simple, yet clean and explicit break.
> We want to keep the #ifdef magic for them to a
> minimum, which would be easier with keeping the libusb.h name.
If app developers are that indecisive about switching to libusbx, and/or
don't want to perform extra steps they would have to perform themselves,
with any 2 other established independent libraries, I seriously advise
them to consider sticking to libusb.
> Looks sane. One option would be to give the callback an action argument
> which is an enum of { added, removed } (for now). And warn in the doc
> we may extend the enum.
Extending an enum (as long as we don't modify any existing values) isn't
API breakage. I think we've done some of it for libusb already in 1.0.
As to adding an enum to the callback, while it looks OK, I'd prefer
having at least brought up my hp branch back to libusbx current before
greenlighting the API change.
> On the topic of 2.0, I've one more addition to the API change list,
> drop the libusb_kernel_driver_active / libusb_detach_kernel_driver /
> libusb_attach_kernel_driver functions (to be replaced with
> libusb_ioctl).
Good point. Expect a proposed libusb.h diff to be setup tomorrow, so
that we can discuss further.
> I expect to have libusb_ioctl patches within a couple
> of weeks, and otherwise we could just not have these for the first 1.9.x
> release ..
Great. I'll be working on internationalized strerror as soon as I get
much of this current unexpected stuff out of the way.
Regards,
/Pete
[1] https://github.com/libusbx/libusbx/issues/47
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
