Andrei Tchijov wrote:
> I think I know the answer now ( after our somewhat prolong discussion
> about merits of fpusb ), but I want to ask the question anyhow. Do
> you not consider relines to glib ( and imageMagik to some degree ) to
> be bad thing?
I chose to use glib at the very start for a mix of convenience and
portability, but after actually writing the code I've also realised that
I haven't used it a huge amount and I haven't really had to use the
parts of it that improve portability. So yes, that might go away.
ImageMagick is only used as a workaround for a NBIS bug and will
hopefully go away in future. It is only used for AES4000.
> Sort of along the same lines ... should fprint really use NIST code in
> such a "intimate" way? NIST is free/open source/good, but it is not
> the only recognition package.
It's the only one that works that I know about :)
If that were to change, I may consider adding a layer of abstraction
there. We may even end up including 2 engines at some point, if we
cannot fix NBIS to work well for images from small sensors.
As for the other points, I'd accept reasonable patches for:
- configure-time control for excluding all enroll/verify/identify
functionality, NBIS, etc
- better defining relationships between drivers and dependencies.. for
example aes4000 is the only imagemagick user, and uru4000 will soon
grow a dependency on openssl's libcrypto
- configure-time control over which drivers get included (hence
including the ability to exclude imagemagick/openssl deps)
The reason these aren't in place already is because there is lots of
work to do all over the place and my priorities are elsewhere. Patches
or feature request bugs are welcome.
Daniel
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
