Re: Online Accounts panel for 3.2

[David Zeuthen <zeuthen gmail com>]

Hi,

On Wed, Apr 27, 2011 at 1:16 PM, Alberto Mardegan
<mardy users sourceforge net> wrote:
> 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).

Oh, that old thread. Well, I'll just repeat what I've always been
saying: if a factor of 4 going to kill you, then you are already using
D-Bus incorrectly. Either way, as I said in bug 634471 (which is where
discussion of GDBus performance should take place), I'm not opposed to
optimizing GDBus - I just want someone to actually benchmark things
sensible instead of this completely baseless "GDBus is slow"
non-sense, sorry. And, btw, if you are already using libdbus-1 and/or
libdbus-glib-1 you should worry about threading instead of
performance.

>>>> 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.

I'm talking about having 1000 Unix users on a big box (or each on
separate boxes). For example, if I'm a sysadmin for the City of Largo,
then it would be nice if I could just drop a file so that the "City
Events" calendar account is included for each account. This is nothing
new - it's what we've been doing with GConf defaults etc. forever.

>
>> 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).

I don't think any client except the configuration UI is supposed to do
any set calls. And, btw, setting a D-Bus property from a client app
has no error checking (same way g_object_set() has no error checking)
because the daemon-side is designed to not have writable properties.
So the programmer does not have to worry about the async aspect.

> 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?

I don't think you understand how it works - the _only_ D-Bus call that
is made is the initial GetManagedObjects() D-Bus call. Everything else
is cached in each client and updated in response to PropertiesChanged
signals. That's just how org.freedesktop.DBus.ObjectManager works...

>>>> 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,

Excuse me? Why exactly is this not secure?

> even though I understand that security is not
> the focus of the GNOME desktop.

That's non-sense. Security is just as important in GNOME as in any
other sensibly designed environment.

> 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's fine, we're doing time-based releases. We also specifically don't
want to commit to any stable API for a few releases. So that's why
it's so much better to use something we write in GNOME itself.

> - 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)

It does. See

 http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.Account.html#gdbus-property-org-gnome-OnlineAccounts-Account.SupportedSources

I'm probably going to rename it "Scope" though, since it's more in line

> - every client needs to load all accounts data in memory, even though it
> might use just one account

How many accounts do you think people have? Complaining about memory
use is completely missing the point. Seriously.

> - excessive use of D-Bus, for no good reason (static information should
> be directly accessible)

No, it's fine. You just don't seem to understand how ObjectManager works.

> - monolithic approach to providers and services

It's not monolithic, no. I don't know why you think it is.

> - API doesn't cover some basic use cases (for instance, enumerating all
> account which supports the e-mail service type)

Easily added.

> 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. :-)

Plain GLib? Excuse me. Please realize that all the code is currently
just under 7000 lines of C. Including comments and header files. That
includes a gnome-control-center panel, the daemon, the client library,
the OAuth2 impl using webkit and Google and Facebook implementations.
It's all in one place and we are free to change a lot of things at our
own pace.

     David