Re: Online Accounts panel for 3.2

[Alberto Mardegan <mardy users sourceforge net>]

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

Understandable.

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

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?

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

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
> Type=google
> EmailAddress=zeuthen gmail com
> EOF

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

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

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

[Service some_id/gmail]
EmailAddress=zeuthen gmail com

[Service some_id/google-talk]
DefaultPresence=online
EOF

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.

Ciao,
  Alberto

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