Re: Online Accounts panel for 3.2

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

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

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

cryptsetup and dm-luks can be easily removed -- Qt obviously not.
But in any case this is an issue for the SSO part only; libaccounts-glib is not concerned with Qt.

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?

just flat key-value configuration files read from e.g.


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.

If you want to go for the daemon approach, then yes, key-value files are just fine. But then you'll have asynchronous APIs, which seems much more overhead to me than directly using SQLite.

Giving that our main target was a mobile device, trust me that we tried hard to come up with an efficient design which would be simple to use for applications.

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.

But then, how would a certain application get the title and the icon of the GoogleTalk service? Loading a binary plugin?

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

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

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

[Account some_id]
Name=Some Account
EmailAddress=zeuthen gmail com

This is a bit simplistic. I'd rather say:

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

[Account some_id]
Name=Some Account
UserName=zeuthen gmail com

[Service some_id/gmail]
EmailAddress=zeuthen gmail com

[Service some_id/google-talk]

I mean, you need some grouping of service-specific settings; that's why the structure needs to be a bit more complex than what you propose.

I hope I'm not sounding arrogant, but I believe that you haven't well considered many aspects and issue which in MeeGo we have already being stumbling on, and seemingly resolved. At least, I would expect to see a better planned design, before jumping to the implementation phase.


-- <-- geek in un lingua international!

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