Re: Online Accounts panel for 3.2

[Alberto Mardegan <mardy users sourceforge net>]

On 04/27/2011 08:42 PM, David Zeuthen wrote:
> 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.

I don't think that switching to GDbus would kill performances; I'm just
arguing that I don't see a good reason to change some existing code to
use it, since it's not better than libdbus (though it might be better
from a maintainability POV).

> And, btw, if you are already using libdbus-1 and/or
> libdbus-glib-1 you should worry about threading instead of
> performance.

They are thread-safe, aren't they?

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

OK. To have this on libaccounts-glib, you would install a file as
/usr/share/accounts/services/largo-calendar.service
with all the parameters/data to access the calendar. I don't think that
the current implementation of libaccounts-glib supports automatically
enabling newly installed services, but it something which could be added.

> I don't think any client except the configuration UI is supposed to do
> any set calls.

It's not necessary, but it might be very convenient for applications to
store some account-specific settings there. For instance, an instant
messaging application might want to store the default requested presence
for the account (that is, having a property "DefaultPresence" which
would be set to "online", "busy", etc.). Though indeed this data might
be stored somewhere else and bound to the account via the unique account ID.

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

I did understand how it works (or I think so :-) ), but my remark was
formulated quite incorrectly, sorry. You get all accounts data with one
single D-Bus call, and this includes the basic account properties, one
of which is the provider name, e.g. "google".
At this point, IMHO, it would be better if in order to get the Google
icon (and other settings) one would read a static file, whose path is
uniquely identified by the provider name, and get the information from
there. While, if I understand you correctly, you would pass this
information along with the accounts data, in the first D-Bus call.
OK, this probably is not a performance problem in the desktop, but still
it's suboptimal, at least memory-wise.

>> Functionality wise -- cool! :-)
>> Security wise not so much,
> 
> Excuse me? Why exactly is this not secure?

Please read the next paragraph.

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

Sorry, I probably should have clarified better what kind of security I'm
talking about: I'm not referring to network security or even to local
security threats coming from other local users. It's about trusting the
applications that the user installs, and having different access rights.
With this approach, we don't let applications specify their own
application token, and request different authorizations to the account's
data (for the OAuth case).

I beg pardon -- having the word "security" associated with a certain
context for 8 hours per day, I probably abused it here. But this is
indeed the kind of security I had in mind, and I think you'll convene
that it's not something GNOME is much concerned about. :-)

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

Choosing libaccounts-glib would not be committing to a stable API; you
can just try it out, and either propose changes or scrap it completely.

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

Or "Service type". But I think this is not enough, you should at least
have more interfaces on the account object, one for each scope. I mean,
when the e-mail application uses the account, it also needs to know the
address of the server, and a bunch of other settings. Indeed you can
keep these properties on the Account interface (prefixing them?) but I
feel it would be more clean to have a
org.gnome.OnlineAccounts.Account.email interface (if "email" is one of
the supported scopes, of course).

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

>From one to a dozen, typically 5 or less. But you have quite a few
settings/data on each of them (especially if you keep also static
information in there), and you have multiple applications using them. I
agree that no matter how many of them one has, it's not going to be an
issue; but since we can easily avoid this (and without complicating
things), why not do it?

>> - monolithic approach to providers and services
> 
> It's not monolithic, no. I don't know why you think it is.

Well, I would expect that the Google, Facebook interfaces and those
which will come in the future will be delivered as plugins. But seeing
their interfaces already defined in the GOA documentation makes me think
that they are not.

This use case, for instance: in a user desktop, there is no support for
the newly born Moogle instant messaging service. Let's suppose it's
based on the XMPP protocol.
1) How would I (developer) add support for it in GOA?
2) And how would a user get my contribution?
3) And what if Moogle adds an email service later on?
4) And what if the XMPP server address changes later on?

For libaccounts-glib, this would be handled this way:

1) Developing the Moogle provider and IM service:

- I create a moogle.provider file, with just a couple of lines telling
the name and icon
- I create a moogle-im.service file, with again a basic description
(name and icon might be different from the provider's -- think of
Google, GoogleTalk, Picasa) and the default settings for the service:
the XMPP server address, the port. Also, static information about the
supported capabilities, presence states, smileys (these might actually
fit better in a separate file, whose path is uniquely identified by the
"moogle-im" string).
- According to how the account setup works in GNOME, I either create a
plugin for the accounts control panel applet or just a static file
describing the UI.

2) User installation:
- install a distribution package containing all the above
- configure the account
At this point, Empathy will simply recognize the new account and start
using it.

3) Moogle email:
- create a new moogle-email.service file, again with name, icon, and
default settings such as address of the IMAP server, and so on
- The user just installs the new file, and enables the moogle-email
service in the account configuration

4) XMPP server address change:
- Update the moogle-im.service file, with the new server settings.
- User installs the new file; unless the server address is stored in the
accounts DB (and it will not, if the Moogle account UI wisely didn't
have a field for it), libaccounts-glib transparently reads the setting
from the .service file.


I don't see much point in continuing this discussion anyway... It's
obvious that you have decided to write your own implementation, probably
even before knowing about libaccounts-glib. Though I feel there's quite
some NIH in this approach, I understand that unless I'm able to provide
an alternative implementation of the control panel applet and a Qt-free
version of the SSO, there won't be a chance to prove my proposal. And
I'm certainly not blaming you for that. :-)

Unfortunately though, I don't have time and energy for doing all the
above in my little spare time, so I'd better shut up now and let you do
your work. I'm sure I won't be disappointed from the result anyway. :-)

Ciao,
  Alberto

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