On Wed, Jun 25, 2008 at 12:50 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: > On Wed, 2008-06-25 at 10:41 +0300, Artem Egorkine wrote: >> > Aren't Python bindings moot when we want to promote the use of the D-Bus >> > daemon (and thus free Python bindings through D-Bus introspection)? >> >> Yes and no. It is true that you get free python bindings with D-Bus. >> Personally, that was my first thought when I realized that there were >> no python bindings in the first place. On the other hand, fprintd >> still does not provide the functionality of loading arbitrary >> fingerprint data from binary blobs and identifying a fingerprint from >> a gallery of prints. Correct me if I'm wrong. > > It will as soon as I receive hardware that supports it. I don't see how > much harder it would be than writing Python bindings.
I admit, it aint hard. The functionality is present in libfprint and it is just a matter of wrapping it in D-Bus code. I am curious, however, how would you deal with sending 'struct fp_print_data *' down the line over D-Bus. Especially dealing with an array of these, it would seem extremely inefficient to send the array with each call to the identify function. >> Finally, for a small project that exclusively uses a fingerprint >> reader, I frankly see no point to involve D-Bus when you can talk to >> libfprint directly. > > Which "small project" did you have in mind? > > Given that the daemon takes care of data storage, and device access > permissions, there's a little more to it than using the bare-bones > libfprint API. It is exactly the fact that the daemon takes care of data storage that is not suitable. In my project, and as I understand from reading others' mails, fingerprints are stored in a database. One or multiple instances of the application get the data from the database and store it back. Instances if the application are all running on different computers in the network, each having a dedicated fingerprint reader (all readers are the same make as to eliminate the problem with device-specific data format). To reiterate, the application is the sole user of libfprint and the fingerprint reader and manages its own fingerprint data itself. -A _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
