Re: Online Accounts panel for 3.2

[David Zeuthen <zeuthen gmail com>]

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

The reason is that if you are writing a library intended to be used by
GNOME apps and you are using libdbus each app using it suddenly has
two connections to the session bus daemon instead of just one (one
from libdbus, one from GDBus). This is not very good. The GDBus API is
also a lot nicer if you are used to GLib-style APIs ... then again I'm
a bit biased since I wrote GDBus. But, then again, the original D-Bus
author, Havoc, came up with a lot of suggestions for the GDBus APIs.
See the gtk-devel-list archives for details.

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

Uhm. No. And I know this because I initially based GDBus on top of
libdbus-1 but it failed in pretty spectacular ways once I added
multi-threaded test cases.

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

Indeed.

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

No-one says that we are passing raw image data over D-Bus as
properties - we can do clever stuff like passing a serialized GIcon
instance and have something like a GoaHTTPIcon type in the
client-library. That way we'll just pass an URI in that serialized
GIcon data. See

 http://git.gnome.org/browse/gvfs/tree/client/gvfsiconloadable.c?h=gnome-3-0

for similar tricks done in GVfs to load thumbnails directly from the
device. We could also just decide to not have any icons/images be
properties - instead, we can just provide a D-Bus method to get the
icon/image. Then the implementation can read it directly from the
network if wanted.

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

For the record, I think it's wrong to say that GNOME isn't concerned
about it and it's something at least I take offense at. And I'm
honestly not sure why you think GOA is that much different from your
stuff. For OAuth2 based services, which is all we support right now,
applications can only get the so-called "Access Token" from
goa-daemon, cf.

 http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.AccessTokenBased.html#gdbus-method-org-gnome-OnlineAccounts-AccessTokenBased.GetAccessToken

You know... if we wanted, we could be more discerning and put up dialogs like

 "GWibber is requesting access to your Twitter account [Deny] [Allow]"

much like we are already doing for system services via polkit cf.

 http://davidz25.blogspot.com/2011/02/gnome-3-authorization.html

but since the desktop is already one security context already, this is
more or less just pointless snakeoil. It would look cute though :-)

FWIW, I agree such dialogs make sense in the case where you have a
proper security architecture, like on Android, and each app is truly
its own security context and can't ptrace(2) each other and so on.
Last time I checked, this wasn't the case with Meego, maybe it's
different now. I don't know.

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

You are conflating things here - having things like the address on the
server would probably be a big mistake. For example, if the 'scope' is
'messages', it only means that the the provider (e.g. 'google',
'facebook', 'yahoo', 'twitter') has some kind of concept that maps to
what GOA has defined as 'messages'. So if you are an email program and
you are using GOA then your code needs to look like this

 if type == 'messages':
   if provider == 'google':
     use APIs at http://code.google.com/apis/gmail/
   elif provider == 'twitter':
     use APIs at
http://apiwiki.twitter.com/w/page/22554699/Twitter-REST-API-Method:-direct_messages
   elif provider == 'facebook':
     use APIs at https://developers.facebook.com/docs/reference/api/message/
   elif ...

and that's it. So it's like this: GOA provides only two things: the
access_token and the fact that the user has configured this account
along with some well-known meta-data. IOW, GOA is _not_ intended to
actually give you any of this data - the intention is that this is
left to higher-level libraries such as libsocialweb, e-d-s and so on.

Now, we _could_ have a provider that is just called 'generic_email'
where the experience is that the user can enter addresses for IMAP,
SMTP servers... port numbers... username/passwords required to use
these... auth types... and other such confusing stuff that everyone is
actively moving away from real fast.

What probably _does_ make sense, however, is to have standard
interfaces such as org.gnome.OnlineAccounts.IMAPBased such that your
mail application works like this

 if type == 'messages':
   if provider == 'google':
     use APIs at http://code.google.com/apis/gmail/
   elif provider == 'twitter':
     use APIs at
http://apiwiki.twitter.com/w/page/22554699/Twitter-REST-API-Method:-direct_messages
   elif provider == 'facebook':
     use APIs at https://developers.facebook.com/docs/reference/api/message/
   elif obj.implements(org.gnome.OnlineAccounts.ImapBased):
     use IMAP API against the address obtained from ImapBased.GetAddress()

Maybe that's what you meant?

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

For GOA, the developer would simply write a GoaBackendProvider
subclass and drop it in e.g.
/usr/lib64/goa-1.0/extensions/libmoogleprovider.so. This
GoaBackendProvider subclass would then make sure that the exported
GoaObject implements the org.gnome.OnlineAccounts.XMPPBased interface
(still to be defined - but would include things like the XMPP server
address). Then Telepathy, or however you are using XMPP, is able to
pick it up from GOA.

We could have a generic GoaBackendProvider that just reads XML files
so the Moogle developer don't have to write code. I don't think that's
useful though. And as I said earlier, it is premature to have GOA
support plug-ins so right now it isn't reading stuff from
/usr/lib64/goa-1.0/extensions.

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

I did know about libaccounts-glib before I started this work. I also
sent out mail to d-d-l last week. And I explained why I don't think
it's in GNOME's best interest to use the libaccounts-glib this
morning. To call what I'm doing NIH is honestly not very nice. You can
also check the commit log of GOA - I only started writing this nine
days ago... it's just not that much code and it just doesn't need to
be that much code.

    David