Yes true. But I'm not creating an app for the system specifically. So I don't want prints to be stored as if they were for a user of the system. This will be an app running as a single user but it will work with many persons, not users of the system. But users of my specific app. If I could save prints to my own identifiers for users and then let it identify amongst them that would be great.
But maybe I should just use libfprint directly then? Are there any python bindings for the async version of the lib? On Wed, Dec 10, 2008 at 1:23 AM, Bastien Nocera <[EMAIL PROTECTED]> wrote: > On Tue, 2008-12-09 at 23:44 +0100, Linus Färnstrand wrote: >> I don't get why the storing and handling of fingerprints should be >> done in the daemon? >> I extended the signal EnrollStatus to return the print data. >> Now to the hard task. to implement the IdentifyStart/Stop methods and >> sending all the print data over dbus and reconstructing the print data >> structs. >> >> Don't you think this would be a much nicer solution? > > Certainly not. That would mean that every application has to reimplement > reading and writing to the database and, more disturbingly, that user > applications can have access to all the fingerprint data. > > This is just about as good as having all the passwords for the system on > a post-it note attached to the monitor. > > > _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
