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?
One of the ideas behind the daemon is that applications can use fprint *without* having to implement their own storage backends. This simplifies things for application developers. Otherwise, if there were 100 fprint-integrated applications, then we'd have 100 different fingerprint storage systems with no interoperability. yay. Based on your comments so far, it sounds like you may be better working one step lower in the abstraction -- using libfprint. Alternatively, we'd be happily consider exposing this information at the dbus level through fprintd, if you want to propose API modifications and patches to make that so :) Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
