Re: Online Accounts panel for 3.2


On Wed, Apr 27, 2011 at 10:52 AM, Alberto Mardegan
<mardy users sourceforge net> wrote:
>> 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...

What do you mean by "slower implementation"?

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

I just don't think it's good for storing user configuration.
Especially not on multi-user or managed- systems where it's useful
being able to configure 1000 users by dropping a simple file in /etc.

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

Not necessarily. My implementation is using the upcoming
org.freedesktop.DBus.ObjectManager so all the async issues basically
go away. See

for the API. OK, so getting the initial GoaClient object is an async
op (you can do it sync which is fine - it's a local RPC call that is
guaranteed to return very quickly), but from there it's smooth sailing
- you get property changes and so forth for free.

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


In C, this would be

We could easily add support for getting the icon as well.

Or if you are dealing with a Facebook account, you'd use the Facebook
specific interfaces

to get information. Again, we can add more stuff as needed.

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

See -
there's also a video of how the panel.

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

Because of the concerns I voiced in the last mail.


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