[fprint] Question regarding fp_print_data_get_data()

[Mehmet Ali Akmanalp]

> 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.


Although I'm all for the binding, this could be overcome by not exposing the
internals at all to the client application. If storage data is needed, the
serialized versions would be sent back and forth. I don't know if there
would be a huge performance hit, since the event of scanning a fingerprint
occurs quite infrequently in terms of computer operations -- scans are at
least 1-2 seconds apart.


> 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).


Same problem here. I have a specific dir that I need to write the data into,
and that requires certain elevation, etc. This elevation will be determined
by a policy manager, depending on the permissions that the given user has
for each operation. Storing fingerprint data under each users homedir
honestly doesn't seem like the best way to do it, at lest from my POV.
Furthermore, there is the problem of migrating to libusb 1.0 that I
mentioned before, and the fact that waiting for fprintd and libusb to become
stable, it going to take a healthy amount of time and testing.


~ Mehmet Ali Akmanalp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.reactivated.net/pipermail/fprint/attachments/20080625/cd853b8b/attachment.html