Daniel,
I am sorry to say, but I am the one of "people" who will be not happy
with this development. I start using your drivers when it was dpfp
and was able to port it to Mac OS X/Windows(cygwin)/Solaris without
many difficulties. I was (and still is) very excited about fprint
project -- mainly because much wider support for scanners. Just last
week, I was able to "port" fprint to Mac OS X in about an hour.
Switch away from libusb will be rather unfortunate development for my
projects.
Maybe I am missing something, but what are the benefits of
"asynchronous API"? It is easy enough to start new thread for
anything that needs to be done "asynchronously". Could you please
elaborate a little bit about why "asynchronous API" is so appealing?
In general non-blocking APIs are beneficial in situations when you
need to wait on many (100s-1000s) data sources -- like in case of web
servers with bunch of users -- I can not imagine situation when fprint
will be used to wait on more then one data source at a time. Am I
missing something?
Andrei Tchijov
On Dec 2, 2007, at 18:26 , Daniel Drake wrote:
> libfprint currently uses libusb for USB I/O. It has been working well
> but limits our horizons - it makes cleanly implementing some advanced
> features difficult/impossible and prevents us from providing a
> non-blocking API to library users.
>
> I considered switching to OpenUSB but decided that I do not like their
> solution for a few reasons.
>
> So I wrote my own USB access library called fpusb.
>
> http://www.reactivated.net/fprint/wiki/Fpusb
>
> I will soon start a new libfprint branch in the git repository where I
> convert us to fpusb and then start using the advanced features
> (involves
> quite a bit of internal reworking, including rewrites of all drivers).
> The basic model is that all drivers will be nonblocking and will
> asynchronously drive the library. The library will provide an
> asynchronous API to users, as well as a synchronous API (basically
> just
> wrapping the async stuff) similar to the one currently offered.
>
> This new branch will likely be rebased without warning until we reach
> the point where I merge it into the master branch.
>
> Unfortunately, the switch to fpush means that portability is somewhat
> reduced. Previously, libfprint was likely to be portable to OSX and
> windows without too much hassle (because libusb is ported to those
> platforms). fpusb only runs on Linux. I hope that people will become
> interested in porting it, but as I am not going to do this myself, I
> cannot say if/when it might become possible to run libfprint on other
> platforms.
>
> This is not an easy decision to make, but the advantages of having
> asynchronous USB I/O access are significant, and exposing a
> nonblocking
> interface is important for good library design.
>
> Daniel
> _______________________________________________
> fprint mailing list
> [email protected]
> http://lists.reactivated.net/mailman/listinfo/fprint
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
