Lei Chen wrote:
> Daniel Drake wrote:
>> Sophia Li - Sun Microsystems - Beijing China wrote:
>>> Good question. OpenUSB is a forked project from the libusb 1.x branch as
>>> Xiaofan has indicated. We have been focusing much on the development
>>> work and haven't considered about the naming seriously.
>>> What is the usual practice for a forked project? Keeping the original
>>> binary names or using different names derived from the new project name?
>>> Although there is a compatibility layer, we still cannot be sure the new
>>> lib can support all the libusb 0.1 applications. Do we need to allow the
>>> coexistence of the 0.1 lib and the new lib? If they are to coexist, the
>>> new lib would need to be named differently from libusb.so.
>> I can't think of any perfect examples, but here's one: wodim, which is a
>> fork of cdrtools. It does provide compatibility with cdrtools by the use
>> of symbolic links, but is otherwise renamed. The situation is a bit
>> different there because cdrtools is still an active project under
>> another license.
>> Another example: beep-media-player when it forked XMMS. They originally
>> called it XMMS2 because XMMS was seemingly dead project. But XMMS
>> developers complained of this bad practice, XMMS2 renamed to beep, and a
>> little while later we even see XMMS upstream revived with a different
>> XMMS2 project.
>> I would suggest renaming the library to libopenusb.so, the header to
>> openusb.h, and the API functions from libusb_ to openusb_
>> libusb-0.1 compatibility is a nice idea, I see there is also some compat
>> code that I missed (but no header file). I would suggest decoupling this
> We may need to provide the libusb 0.1.x header file, though this file
> has a very slight difference on Solaris from Linux, if we want to
> completely replace libusb 0.1.x with openusb.
>> from the main library and instead install a separate one. i.e. we have
>> libopenusb as mentioned above but without any compat code, then we build
>> the compat code into a file called libusb.so which links against
> We may still need a new name here. libusb.so is for libusb 0.1.x and has
> different implementation on platforms. Take Solaris for example, there's
> a wrapper layer that provides support for different plugins. Some
> plugins will not be turned to OpenUSB architecture soon. To make them
> still work, libusb.so has to be kept for a period.
> On the other hand, will this separate compat layer add complexity for
>> libopenusb. The header file should also be appropriately decoupled. (I
>> would still suggest that both libs are shipped in the openusb source
>> distribution - I'm not suggesting separating them on that level)
>> This has a few advantages, notably that it's easier to install
>> libopenusb without the compatibility cruft (which some embedded users
>> will likely appreciate), it'll be easier in future to drop the compat
>> layer which may happen at some point, it makes it easier to
>> conditionally build the compat layer if that's an approach you would
>> want to support (which in turn makes it easier to install libusb
>> alongside openusb), and it would also help to avoid confusion with the 2
>> APIs (I feel that it's likely that someone would accidentally use the
>> old libusb API if it were not decoupled like this).
> OpenUSB provides emulation layer for backward compatibility for old
> applications. We may not expect all old applications turning to libusb
> 1.0 APIs in the near future. For new applications, they are encouraged
> to use new APIs, the libusb_*.
> FYI, some useful links:
> 1)OpenUSB wiki: http://openusb.sourceforge.net/wiki/index.php/Main_Page
> 2)A fingerprint project on opensolaris.org:
> Best Regards,
> Lei Chen
Personally I think there's no reason we need to call any part of it
The API is substantially different now.
It is better each project controls their respective namespace
independently without having to
coordinate. This completely avoids collisions with no headache.
OpenUSB project was forked for the purpose of being able to go in a new
unencumbered. Having loose-ends between the two projects just
complicates things for everyone.
By replacing every occurrance of libusb with openusb, there is a fresh
start. Ambiguity is eliminated.
t makes things 100% clear to end users which is which, which is what
we want. The ideal is there is
/never/ any conflict by /anyone/ at /anytime/ functionally, and also no
confusion as to where people look
online to find information about the project. I think that is very
important. Such enduser concerns
should be fundamental in all questions regarding public-facing software,
such as this.
If people they see openusb* names in the libraries or function prefixes
they'll look for the openusb
project page the net without having to do any extra research. If they
see libusb-1.0.so. or libusb prefixes,
it will only tend to confuse people because there are two projects
providing the same names.
There is nothing special about the name libusb, besides the fact that,
so far it is the only
one people have heard. OpenUSB is as good a name, and maybe even
it doesn't imply UNIX-like platforms, as libusb does.
As far as people knowing about and being able to find OpenUSB goes.
that's going to happen
as time goes on anyway and both APIs are discussed and compared on the
'Net and in forums.
OpenUSB will rise in the search engine indexes, and tend to show up in
places where libusb
is discussed to people can compare the too projects and decide what the
best fit is for their
needs. The more incoming HTTP links on the net to the OpenUSB project,
it will rank in search engine look-ups. So I don't think visibility or
familiarity is enough
of a reason stick with the libusb namespace either.
Just my two cents.
>> Depending on feedback to these ideas I may post some patches to do this
>> next week.
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> Libusb-devel mailing list
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> Libusb-devel mailing list