Please do not take any offense from my comments below. fprint is great project and you -- as a author of the project -- most certainly have all rights to move it in any direction you want. At the same time, I do realize that my project is not very "main-stream" ... still fprint ( and dpfp before ) is best fingerprint scanner access project and I really hate if I will need to start looking fore another one ... and to the best of my knowledge there is no other(open source/free) one.
On Dec 3, 2007, at 10:37 , Daniel Drake wrote: > Andrei Tchijov wrote: >> 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". > > I assume you are talking about the libfprint API, not the fpusb one. Thats correct > > > My answer: threading shouldn't be necessary - and as I will show > with my upcoming work, it isn't! I don't want to make something > unreasonably complex when it can quite easily done in a simple > fashion. > > > Could you please >> elaborate a little bit about why "asynchronous API" is so appealing? > > The async API is only part of the reason for the development > direction here, but it is simply nice to have. It avoids having to > create threads in certain types of applications (e.g. GUIs) to call > libfprint. In almost all cases, threading an appliation adds a > degree of complexity, which is obviously avoided when you don't have > to create threads. I guess this is question of personal preferences. I do not think that threading is either complex or difficult. All modern OS's provide well defined rich and easy to use set of APIs for threading ... ironically Mac OS is the one OS which trying really hard to make people NOT to use threads (they are really big on "RunningLoop"), but at the same time Mac OS X does provide nice set of APIs to do threading (and the fact that FInder is much much faster in 10.5 then in 10.4 is entirely due to the fact that it was re-implemented as true- multi-threaded application) > > > It also allows more efficient integration with applications that > sleep on multiple event sources. Beside process of enrolling which require some sort of GUI which in turn may get into "sleeping on multiple event sources" when exactly this become an issue with fingerprint authentication? I always thought that main usage of fprint project is to implement some sort of authentication scheme. When you authenticate someone do you really need/want to do anything else until you got his/her fingerprint? > > > The more significant advantages of switching direction here are > expressed in terms of library internals. > > For example, there currently is no way to cancel an ongoing > enrollment request. If we were to implement this in the current > model, it would involve forcing the application to have 2 threads > calling into libfprint simultaneously (one calling enroll, and > another one trying to cancel the request). Internally within the > library, we would have to switch from long/infinite USB timeouts to > very short ones (to provide acceptable response time for cancel > requests) which will drain battery life. And overall the > implementation would just be hacky. "Enrollment" == "GUI". Once we talking about GUI the whole issue of threading become murky one. Most GUI toolkits provide you with some sort of threading substitutes to help with off-loading functionality which require lots of time from "main thread" ( timeouts/signals/idle function ). So application does not have to have "2 threads", just use that "off-loading" API to do enrollment and call cancel API from "normal" GUI callback. To tell the truth, I am not sure I will buy argument about "... short timeouts ... -> ... draining battery life... ". I do agree that short timeouts will somewhat increase CPU load, but I do not believe that such increase is big enough to cause noticeable reduction in battery life > > > The external async API will allow us to offer a nice cancellation > API, but more importantly, the whole idea of cancellation is not > possible internally without being able to do async USB I/O, and > that's the real advantage here. You have described possible approach to cancellation API which does not require async API in previous paragraph :). > > > Also, by having drivers asynchronously drive the library, we can > implement more advanced features which would otherwise be quite a > nightmare. For example, finger resampling. When the user presses > their finger on the sensor, the first image that comes back isn't > very good. We want to capture a few images. But we also want to be > aware that the user may remove their finger at any time. Rather than > massively complicate the internal driver API, we can simply reverse > the data flow: the driver tells the library when a finger is > present, informs the library when an image is ready, and tells the > library when a finger is removed -- regardless of what the library > and it's users are doing at that point in time. It'll improve driver > quality quite a bit. Why can't we have API which can be called over and over in a loop and which will keep returning new images of the finger over and over again until finger is removed? I guess I could be missing something here ... I do not know enough about internal driver API to judge how much efforts such API will require. > > > There are other plus points too. Another one that jumps to mind will > be increased USB performance by queueing multiple URBs > asynchronously. This will decrease the inner-loop time for imaging, > which will result in further improved imaging performance from the > authentec swipe devices. Again, I am not an expert, but does it really that important? We are talking about very small amounts of data which need to be transfered (fingerprint image is very small and grayscale), USB should be fast more then enough for this kind of operations. > > > At the end of the day: > - the library is more efficient > - more advanced features will be implemented, resulting in improved > user experience > - drivers will work better > - imaging will work better > - async API will be offered > - crucial missing functionality will be added > - integration into a wider range of applications will be easier > - for the people who still don't like the above, they can continue to > use the existing API (which will remain, maybe with some slight > modifications) - no big deal! Unfortunately, all statements above except last one and the one about "crucial missing functionality == cancelation API" are not very "concrete" . And about last statement : If I understand correctly, you are not planing to keep libusb based version of fprint around, so people who like new APIs, but do not like switch from libusb, will not be able to use these APIs. > > > I am grateful for your porting efforts so far and am a little sad to > lose portability. But, I do not feel this is permanent. If someone > will step up and put effort into porting fpusb to other platforms, I > *will* help. Are you interested? > > > I just took a quick look at the libusb darwin port. It is only 1000 > lines of code. It uses async I/O internally to offer libusb's sync > interface - so we already have a basis for async USB I/O. The only > missing piece is a pollable file descriptor, but if it is not > possible/straightforward to get one then you could relatively easily > emulate it with a thread and a pipe (I am prepared to be lenient and > allow non-Linux backends to create threads in the interest of > portability). > > The author of the libusb port - Nathan Hjelm - is still active and > is working on a darwin port of libusb. Maybe he would be interested > in helping too, but at the very least I imagine he would be happy to > answer questions about Darwin's userspace I/O API and the libusb/ > openusb implementations. I am not concern that much about Mac OS version, it is "nice-to-have" port for me and the only reason I am starting with it is because my main development box happen to be Apple. Though I am not USB expert, I am quite sure that looking into libusb code, I will be able to port fpusb to Mac OS X (though I hardly will be able to consider this time well spent). Windows is much more important for me. My experience with Windows is almost none-existent (though I am doing software development for more then 20 years, I was fortunate enough to avoid "dark side" :-) ), the only reason I was able to use dpfp on Windows before is the fact that libusb was ported to Windows by some one else. Libusb-Win32 is basically dead project (last release was back in 2004). I do not think it will be easy to find anyone who will be interested in porting fpusb to windows - what for?. Libusb porting efforts were spearheaded by the fact that there are quite a few Linux apps which rely on this API. As of now fprint is the only app which rely on fpusb and even if this project will have supper well-received, it will take years to get to "critical mass" - when enough projects depend on it to justify someone porting it to Windows (or Solaris or AIX ) > > > Ultimately in addition to libfprint working again, you'll also have > laid the way for other projects. There is demand for a userspace USB > I/O library that does async USB I/O. I plan to stabilise and release > mine fairly soon, whereas the other alternative (openusb) does not > seem to have a release in sight. Even when both are released, fpusb > will offer more integration opportunities than openusb. In other > words, I am anticipating interest from other projects in using > fpusb, so I am hoping that porting efforts are inevitable and will > be well-received :) > > Daniel > _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
