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,


kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen

Attachment: signature.asc
Description: This is a digitally signed message part.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to