Re: [Evolution-hackers] Further thoughts on ESources
On Mon, 2011-09-12 at 13:30 +0200, Christian Hilberg wrote: > Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes: > > > >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? Yes, in fact the more I think about the problem the more I'm convinced that this new low-level D-Bus service should handle user authentication prompts in a manner similar to PolicyKit user prompts. (In other words, PolicyKit handles user prompts itself and doesn't force each and every PolicyKit client to deal with it -- so we can mimic its solution for address book and calendar authentication.) > 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 ;-). I mentioned earlier that with E-D-S moving to EExtension, the D-Bus services can now be extended for purposes other than simply registering new backend types. Perhaps this is a use case. I'm woefully ignorant about most security APIs and the issues they try to address. I can help with the nuts and bolts details, but for more conceptual questions (such as those raised in your security post), I'd recommend consulting with and possibly bringing into the discussion Stef Walter -- the gnome-keyring author -- who is more aware of the state of NSS vs. Gnutls and has been helping to add security support to GNOME libraries. He might even have a ready-made solution to your token issue in one of his libraries. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Further thoughts on ESources
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 GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Further thoughts on ESources
On Fri, 2011-08-26 at 10:30 -0400, Matthew Barnes wrote: > Reconnect? The usage pattern I envision for proxy object is to > connect, obtain all the sources somehow (details TBD), and then just > listen for the occasional add/remove/change signal. If the proxy has > to reconnect and refresh its set of sources, it's trivial to filter > out by UID the sources it already knows about. > > Point is, all the details should be hidden in the proxy object. > Should be transparent to clients. Hi, yup, if it'll be transparent and the consumer will not crash on Source factory crash, then that's what I was hoping in. The thing is that I stopped receiving "Remote peer vanished" on factory crashes for some reason. I didn't investigate further, but I've a feeling it has something to do with "close connection" change done recently. Anyway, will see when I find a mood to investigate here further. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Further thoughts on ESources
On Fri, 2011-08-26 at 07:39 +0200, Milan Crha wrote: > sounds good. One thing for a process name, it would be better to call it > evolution-source-registry, because Chen mentioned similar for factories > as well, but we never took a consensus on it and thus their name was > never changed. Yeah, maybe. I think the bus name is more important than the process name. Currently we have: org.gnome.evolution.dataserver.AddressBook1 org.gnome.evolution.dataserver.Calendar1 perhaps the new service would be named: org.gnome.evolution.dataserver.Sources0 > One question comes on my mind: what will consumers do if the registry > process crashes? As long as you want to make it extensible, and the > example of exchange extension of doing stuff on a server, then it can > sometime result in a crash for sure. And seeing a flood panic on all > consumers might be sort of fun. Reconnect? The usage pattern I envision for proxy object is to connect, obtain all the sources somehow (details TBD), and then just listen for the occasional add/remove/change signal. If the proxy has to reconnect and refresh its set of sources, it's trivial to filter out by UID the sources it already knows about. Point is, all the details should be hidden in the proxy object. Should be transparent to clients. > Pity I didn't notice existence of the GDBus code generation tool before > I wrote all the templates for GDBus calls by hand. Though with all those > macros it seems to me like easier to read, if anyone would ever like to > read it. ;) I think David added the code generation shortly after you wrote all that out by hand. I remember thinking of the irony when that landed. We could look into using the code generation tools for 3.4 if you think it's worth it. Since it's in GLib now I don't think we'll get stuck in the "generate once and it rots forever" trap like last time. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Further thoughts on ESources
On Thu, 2011-08-25 at 12:46 -0400, Matthew Barnes wrote: > 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 > > > The e-source-registry process would be extensible of course, with its > own set of dynamically loaded modules. Hi, sounds good. One thing for a process name, it would be better to call it evolution-source-registry, because Chen mentioned similar for factories as well, but we never took a consensus on it and thus their name was never changed. > I haven't worked out all the logistics or a D-Bus API yet, so this is > still a bit hand wavy. One question comes on my mind: what will consumers do if the registry process crashes? As long as you want to make it extensible, and the example of exchange extension of doing stuff on a server, then it can sometime result in a crash for sure. And seeing a flood panic on all consumers might be sort of fun. > But the new GDBus code generation tools in GLib > 2.30 should make this fairly easy to set up. It was for David when he > wrote GNOME Online Accounts. And it feels like the right direction. Pity I didn't notice existence of the GDBus code generation tool before I wrote all the templates for GDBus calls by hand. Though with all those macros it seems to me like easier to read, if anyone would ever like to read it. ;) Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Further thoughts on ESources
Now that my head's back into account management issues, I wanted to brain storm about something that's been knocking around in my brain for a few weeks. Seeing how David Zeuthen implemented the Online Accounts service I think has influenced my thinking. Right now on the account-mgmt branch I've got this ESourceRegistry singleton class which collects all the ESource objects in one place and monitors the corresponding key files and the directory they live in for changes. http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ESourceRegistry.html However, every process -- be it the addressbook/calendar factories, Evolution or any other client -- will need its own ESourceRegistry instance and hence would be doing its own file monitoring. The idea is through file monitors all the processes are supposed keep their ESources in-sync. I think that approach would probably work in practice -- since ESource contents will rarely change. But it feels increasingly wrong to me from an architectural viewpoint. Consider this: the GNOME Online Accounts integration module I wrote recently lives in Evolution, which is clearly the wrong place for it, but we don't currently have a place for it in Evolution-Data-Server. That means if you set up a Google account through Control Center, your Google Calendar appointments will not show up in GNOME Shell calendar until you start Evolution so that the "online-accounts" module can set up ESources for you. 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 The e-source-registry process would be extensible of course, with its own set of dynamically loaded modules. That would give the "online-accounts" module a more natural place to live, and would help strip Evolution of its special E-D-S privileges, making it closer to being just another E-D-S client, which I think has always been the intent. Moreover, it would give groupware extensions (Exchange, etc.) a place to install modules that can monitor an account and keep local ESources in sync with remote resources. For example if a new calendar shows up on an Exchange server (perhaps from the user doing stuff through the web), the Exchange e-source-registry module could notice the change and define a new ESource for that calendar. All without ever starting Evolution. I haven't worked out all the logistics or a D-Bus API yet, so this is still a bit hand wavy. But the new GDBus code generation tools in GLib 2.30 should make this fairly easy to set up. It was for David when he wrote GNOME Online Accounts. And it feels like the right direction. Once I get the branch building again, I think I'll spend a little time playing with this idea and see if it pans out. Comments? Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
