Re: Online Accounts panel for 3.2

[Alberto Mardegan <mardy users sourceforge net>]

Hi David,

On 04/27/2011 07:10 PM, David Zeuthen wrote:
> On Wed, Apr 27, 2011 at 10:52 AM, Alberto Mardegan
> <mardy users sourceforge net> wrote:
>>> On dependencies: we are trying hard to move away from libdbus-1 and
>>> libdbus-glib-1 towards GDBus.
>>
>> As far as libaccounts is concerned, this can be changed easily -- although I
>> don't see a real benefit in moving to a slower implementation...
> 
> What do you mean by "slower implementation"?

Well, you should know I guess. :-)
http://lists.freedesktop.org/archives/dbus/2011-January/013981.html

Whether we trust the test is another issue (I didn't try it myself), but
anyway I don't see strong reasons for changing an existing piece of code
to GDBus (of course, if we were talking about newly written code, things
would be different).

>>> Configuration: I don't think SQLite is at all what we want.
>>
>> Why not? Is it an unwanted dependency, or do you think that using it is
>> overengineering?
> 
> I just don't think it's good for storing user configuration.
> Especially not on multi-user or managed- systems where it's useful
> being able to configure 1000 users by dropping a simple file in /etc.

I'm not sure I'm following you... If by "1000 users" you mean "1000
accounts for one user", then even in libaccounts-glib case that's just
one file.
If you are talking about real 1000 users, each one having some accounts,
libaccounts would indeed require you to have 1000 different files -- but
I don't see how this could be different for GOA: would you store the
accounts of 1000 users in a single file? In any case, I fail to see the
use case for it.

> Not necessarily. My implementation is using the upcoming
> org.freedesktop.DBus.ObjectManager so all the async issues basically
> go away. See
> 
>  http://people.freedesktop.org/~david/goa-20110427/
> 
> for the API. OK, so getting the initial GoaClient object is an async
> op (you can do it sync which is fine - it's a local RPC call that is
> guaranteed to return very quickly), but from there it's smooth sailing
> - you get property changes and so forth for free.

Neat. I would also suggest you to do the same thing when changing the
accounts: that is, instead of having an async/sync version of every _set
method, just have a synchronous one which sets the value locally, and a
per-account sync method (or even on the GoaClient).

>> But then, how would a certain application get the title and the icon of the
>> GoogleTalk service? Loading a binary plugin?
> 
> By
> 
>  http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.Account.html#gdbus-property-org-gnome-OnlineAccounts-Account.Name
> 
> In C, this would be
> 
> http://people.freedesktop.org/~david/goa-20110427/GoaAccount.html#goa-account-get-name
> 
> We could easily add support for getting the icon as well.

Sure. But it beats me that we are making a D-Bus call for something that
could just be obtained directly. Since this information is static, why
not just read it directly from somewhere in the file system?

>>> So as mentioned last week, I was already hacking on something along
>>> these lines that works this way. I'll try to get it into a shape where
>>> it can be shared Real Soon Now(tm).
> 
> See http://davidz25.blogspot.com/2011/04/gnome-online-accounts.html -
> there's also a video of how the panel.

Functionality wise -- cool! :-)
Security wise not so much, even though I understand that security is not
the focus of the GNOME desktop.

>> Good to hear, but why not using something that is already there and offers
>> more functionalities than what you propose (with extensions for providers,
>> service and service-type descriptions, a mechanism of specifying default
>> settings, etc.)?
> 
> Because of the concerns I voiced in the last mail.

Which I hope I addressed?

I see a few issues with your implementation, which IMHO largely surpass
the flaws you noticed in libaccounts-glib dependencies:
- it's not yet ready :-)
- it doesn't have the concept of different services on the same account
(in this respect, I think that your initial proposal was more complete,
because it was mentioning them)
- every client needs to load all accounts data in memory, even though it
might use just one account
- excessive use of D-Bus, for no good reason (static information should
be directly accessible)
- monolithic approach to providers and services
- API doesn't cover some basic use cases (for instance, enumerating all
account which supports the e-mail service type)

I understand that most (if not all) of these points can be addressed and
fixed, or that some of them might not be a concern for the desktop
computers, but it still strikes me why you want to implement a new thing
when there's an alternative which also works on embedded devices.

I totally understand your concerns about using the MeeGo SSO parts
(though I think that even if one decides to re-implement it in plain
Glib, most of the concepts are good and the client API could be quite
similar to that of libsignon-glib -- though admittedly it can be done
better); but for the accounts side, writing a new implementation goes
beyond all logic. Well, my logic at least. :-)

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!