Hi all, Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes: > [...] > Proposal: > > I think the key file management needs to be centralized in a new D-Bus > service, tentatively called "e-source-registry". The ESourceRegistry > singleton class in client programs would then be a proxy for the D-Bus > service. So we'd have a bit of a D-Bus hierarchy: > > > evolution and other e-d-s clients > > e-addressbook-factory | e-calendar-factory > \ | / > e-source-registry Are there plans for any sort of "live service" implemented by this (or yet another component), so that e.g. a backend implementation can query for user input when it needs it? The use case I have in mind originates from the problem we are facing in evolution-kolab backend processes, that we cannot ask for a security PIN (which should not be stored anywhere, but be used-and-forgotten) when opening a security hardware device for a session. If you see Evolution as any one of possibly multiple clients to E-D-S, then it probably makes no sense to pop-up any *Evo* dialogue to ask for the PIN. This would make Evo an even more privileged E-D-S client than it currently is, while my understanding of the current development seems to be to rid Evo of it's privileged status and turn it more into a yet-another E-D-S client. For the problem at hand, we would most probably need some dumb input dialog to pop up, requesting the token PIN, and be gone again - the way security tokens should be used mandates their PIN not be stored *anywhere*, not even in a gnome-keyring or services like that... so I'm curious which plans may exist here (or may need thought-smithing ;-). Kind regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.