Re: Online Accounts panel for 3.2



Hey,

So I had a look and a think about this -

First, I think this is such an important area for GNOME that we want
to be in control of our own destiny - e.g. I don't think the problem
space is well-enough understood that we want to commit to stable APIs
or sharing code with others. Not yet. Maybe when all this is better
understood we can start moving things to freedesktop.org and sharing
interfaces with e.g. KDE, Qt or whatever. But I really don't think
that we are there yet (we've seen with e.g. org.fd.Notifications what
mess it can be if you standardize early).

On dependencies: we are trying hard to move away from libdbus-1 and
libdbus-glib-1 towards GDBus. We also don't want any deps (run-time or
otherwise) on Qt or e.g. cryptsetup or dm-luks. We also really should
be using the platform keyring API (e.g. gnome-keyring) whenever
possible.

Configuration: I don't think SQLite is at all what we want. Instead
just flat key-value configuration files read from e.g.

     $HOME/.config/goa-1.0/accounts.conf
     $HOME/.config/goa-1.0/accounts.d/*conf
     /etc/goa-1.0/accounts.d/*conf

is a lot more friendly. That way, since we'd have a stable
configuration file format, vendors, sites and users can just drop (or
generate) configuration files to reflect their setup [1]. And our
daemon should handle file monitoring so things Just Work(tm) when that
happens. We might also want to use GSettings here but I'm not sure.

We probably want to embed a web browser engine for the Online Accounts
panel - e.g. I don't think it's not good enough to rely on the users
browser with the way e.g. OAuth2 works -- you really want to intercept
the redirect URL and not have to scrape the authorization code out of
a window title (as the Google OAuth2 docs humorously suggests) or have
the user copy/paste it to the panel. In this case we want to use
WebkitGTK+ which has
WebKitWebView::navigation-policy-decision-requested signal to solve
this. All this could probably be made to work in a
platform-independent way (so OtherDesktop can use OtherDesktopWebView)
but I'm just not sure I really see the point in that.

We want all this in a single project with a single set of coherent
docs. E.g. it should be possible to just clone one git repo from
git.gnome.org and then you have everything you need. As equally
important, docs from said project should be in a single doc area on
developer.gnome.org.

I don't think we want any foreign plug-in mechanism (e.g. XML files)
to describe services. Instead, we should have a set of abstract base
classes that e.g. Google, Facebook, Yahoo etc. backends can extend
(and that way share code) and have a GIOExtensionPoint for this. We
won't (of course) load 3rd party extensions from the get-go though.
Maybe later.

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

Thanks,
David

[1] : e.g.

$ cat >> ~/.config/goa-1.0/accounts.conf << EOF

[Account some_id]
Name=Some Account
Type=google
EmailAddress=zeuthen gmail com
EOF


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]