Re: [Evolution-hackers] Further thoughts on ESources

2011-09-12 Thread Matthew Barnes
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

2011-09-12 Thread Christian Hilberg
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

2011-08-28 Thread Milan Crha
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

2011-08-26 Thread Matthew Barnes
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

2011-08-25 Thread Milan Crha
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

2011-08-25 Thread Matthew Barnes
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