Hi,
On 09/29/2012 01:16 AM, Pete Batard wrote:
> On 2012.09.28 08:49, Hans de Goede wrote:
<snip>
>> 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.
Good then we are in agreement, this is really all I want, nothing more
and nothing less.
> But I really can't say for sure what we're
> going to need from cross-platform hp until we actually do it.
I understand.
<snip>
>> 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 disagree strongly here, to me our first and foremost purpose is to
serve our users. Both developer-users and end-users.
<snip>
>> My main worry here is packages which want to be able to build with
>> both libusb versions.
>
<snip>
> 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?
Out of its way, no. But we should try to not make it harder then necessary
for apps to support building against both libusb[x]-1.0 and libusbx-2.0,
by using some configure checks (or some such) + some #ifdef's. This is
very normal in the Linux world. At least 2 projects I'm involved in,
spice-gtk and virt-viewer both support building against the gtk-2.0 or the
gtk-3.0 API.
And I expect to do something similar for usbredir myself wrt libusb[x]-1.0
versus libusbx-2.0. Note that as for libusb-2.0 if that ever happens that
is completely out of our hands, so I could not care less.
<snip>
> 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.
Well for our 1.0.x series the goal is exactly to be so interchangeable
for as the apps to just work the same :) But I completely agree that
with libusb_x_-2.0 that no longer is a goal!
As said I just want to make sure we don't make it unnecessarily hard for
people to support building against libusb[x]-1.0 or libusbx-2.0 for a
while, this is a quite normal thing for projects depending on libraries
to do while those libraries are in an API transition phase.
Also note that we will name the pkg-config file libusbx-2.0.pc, so at
least on Linux even if there ever will be a libusb-2.0, apps written for
libusbx-2.0 still won't automatically try to start using libusb-2.0, but
I understand that that will be less true on windows...
Anyways if re-naming the header from libusb.h to libusbx.h is that
important to you, then lets just do it, and apps wanting to support building
against both libusb[x]-1.0 or libusbx-2.0 for a while will just need to
add 1 more #ifdef.
>> 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.
Right, my point was that having one callback with whether its being called
for add or remove as an (enum) parameter is more extensible then having
2 callbacks, where which callback gets called also passes the info
on whether it is an add or a remove. I can image getting extra
events like device-added-but-no-usable-driver-installed. device-driver-
installed, etc. Which would be easy to add with a callback with an action
parameter.
Regards,
Hans
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
