Andrei Tchijov wrote:
> 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)
Of course, the best way to satisfy everyone is to give them the option -
sync or async.
> 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?
You need good ways of detecting when a device is plugged or unplugged,
it's good to be able to provide a cancel button or to simultaneously
provide the option of entering in a password, etc.
All of these cannot be done in nice ways without the ability to do async
USB I/O.
> 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
www.lesswatts.org demonstrates that if we can avoid programming the
system timer to wake up the system too often, a huge amount of power can
be saved. The minute an app starts polling, all the hard work is wasted.
>> 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 :).
which would be ugly to users and painful to implement internally, and
screams "implement me asynchronously!!"
>>
>> 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.
Yes, it will make a noticeable difference to the devices I mentioned. I
already made a huge improvement since libfprint-0.0.1 in this respect -
just by tweaking the way USB messages are sent, I turned my authentec
scanner from being almost useless to the best scanner that I've got.
This is on a dual core athlon (2.8ghz). It will also improve consistency
when joining the two chunks of data that come back from the DP scanners
- someone already mailed me several images of MS drivers vs my own
software and the smoother images that come from the MS system.
> 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 )
Yes, it's unfortunate that there is some lacking interest in these
areas, but don't rule out the option of a windows port. It may happen
even before fpusb is adopted by other projects:
- there is development going on in libusb-win32 behind the scenes
- the existing libusb-win32 code shows how to do async USB I/O
- vista and recent XP updates include a new well-documented API
(winusb?) for userspace USB I/O. Previously libusb had to use hacks
to hook into the USB stack at the appropriate points, now people can
do it through a real interface.
- companies building windows solutions will hopefully become interested
in using fprint and may be able to provide resources
It seems that our views differ - you put portability first, I am putting
the functionality/quality/performance of this library first. I don't
like to sound uncooperative, but really Linux is my target platform and
this is the direction I have chosen. I am still interested in
portability but as you have gathered it is not top priority. I'm sorry
that this direction is currently not in line with your own work, but I
am hopeful that it the situation will change in future, and I will put
my time towards changing it should assistance appear.
I'm also confident I've provided enough of a base for other people to
continue a libusb-based version should they have time and interest. I
was aware of the problems I am solving with fpusb from the very start,
but nevertheless I decided to write the initial prototype using libusb
anyway.
Daniel
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
