Re: [Evolution-hackers] GSettings Hackfest + Account Storage

[Matthew Barnes]

On Thu, 2010-03-04 at 15:15 +1100, Andrew Cowie wrote:
> But on the third hand, :) GNOME has an increasingly beautiful¹ passwords
> and account management interface in the "Passwords and Encryption Keys"
> tool provided by Seahorse; my understanding is that the APIs underneath
> it are mature too, though I can't speak to that.

Right, I should have clarified that I wasn't speaking of password
information.  That certainly belongs in a secure keyring.  What I was
suggesting we store in key files was account options -- username, host
and port information along with all the knobs and switches you see in
the Account Editor, Calendar Properties, Address Book Properties, etc.

I'll post a more fleshed out proposal to the wiki once I learn more
about the GSettings key file backend.

Matthew Barnes

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] GSettings Hackfest + Account Storage

[Tobias Mueller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Heya :)

On 04.03.2010 04:15, Andrew Cowie wrote:
> On Wed, 2010-03-03 at 15:21 -0500, Matthew Barnes wrote:
>> A secondary goal is to find a saner solution for account settings
>> storage.  I think there's universal agreement that our XML blobs are an
>> abuse of GConf and need to die, but I'm torn on which direction to take.
> 
>> One the one hand, GSettings
> 
>> On the other hand, users...
> 
> But on the third hand, :) GNOME has an increasingly beautiful¹ passwords
> and account management interface in the "Passwords and Encryption Keys"
> tool provided by Seahorse;
Hm. As far as I can see, GNOME Keyring primarily allows to save
passwords and does not support saving Account data very well. The only
API that I found (by having a rather quick glance at
), caters for so
called "Item Attributes". One could probably (ab?)use that API but then
again it doesn't feel much better than storing XML in GConf.

Or is there an API that I missed?

But I'm reluctant to merge credentials management with account
management (i.e. storing both in the same place) anyway.



As for Files vs. DConf: We might want to support locking down of account
settings, i.e. the user shall not be (easily) able to change the SMTP
server. In order to do that, DConf is the way to go.
Also, applications are not supposed to use ~/.${appname} but rather
~/.config/ and ~/.cache/ (or $XDG_DATA_HOME and $XDG_CONFIG_HOME). The
user will thus (hopefully) copy those and DConf will also (hopefully)
adhere to this spec.
Hence, copying those directories is sufficient to move your profile to
another machine.

I worked on migrating XML-in-GConf to plain values in GConf ages ago. I
couldn't finish it and I don't really remember how well it worked, but
it might still be interesting to have a look at the code:


Cheers,
  Tobi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuPph4ACgkQPuBX/6ogjZ4ADQCfY9ttS0wg9hQ9l1/usw4D98Az
BZIAn0ykwZ3hpNiL+Sj+RZpd/OB3NTR+
=E/ds
-END PGP SIGNATURE-
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] GSettings Hackfest + Account Storage

[Andrew Cowie]

On Wed, 2010-03-03 at 15:21 -0500, Matthew Barnes wrote:
> A secondary goal is to find a saner solution for account settings
> storage.  I think there's universal agreement that our XML blobs are an
> abuse of GConf and need to die, but I'm torn on which direction to take.

> One the one hand, GSettings

> On the other hand, users...

But on the third hand, :) GNOME has an increasingly beautiful¹ passwords
and account management interface in the "Passwords and Encryption Keys"
tool provided by Seahorse; my understanding is that the APIs underneath
it are mature too, though I can't speak to that.

Could that store be of any help? Irrespective of the "I want to move
my .evolution with cp" [and isn't that what backup/restore is actually
for?], surely it's better to centralize credential management in the
place that other GNOME apps are using.

AfC
Sydney


¹ beautiful, as defined by the number of apps (today I'm pleased about
Epiphany) storing their username/password credentials there.




signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers