I stumbled over point 3, "user name" as sole key. That's not enough, because completely different Evolution backends (Exchange calendar, Groupwise user list) would have to share a single entry in the keyring. Properly identifying which Evolution backends can have the same password is hard, therefore I suggest to err on the side of caution and use server name, source name, and a fixed string "Backend" (for object) as GNOME keyring keys.

When I say "server name" and "source name", I mean the names as used in the SyncEvolution config ("scheduleworld" + "addressbook", for example). In your list above, did you mean server and proxy URL? That would be consistent with the current way of storing the SyncML server password.

> They maybe not accurate, > but as the first step. > For the parameter list for 'askPassword' and 'savePassword', I'd like to use > the parameter list of keys in the gnome network password. [...]

> See below: > askPassword(string& descr, string& passwordName, string& user, string& > domain,string& server,string& object,string& protocol,string& authtype,unsigned > int port) > savePassword(string& descr, string& passwordName, string& password, string& > user, string& domain,string& server,string& object,string& protocol,string& > authtype,unsigned int port) > > passwordName is the name in the config file for the password, such as > 'password', 'proxyPassword'. This is for 'UserInterface' to decide which > password it will save. I think these names should be unique. > user, domain, server, etc are used as keys of keyring. Yes, this looks like a better approach, compared to granting access to the config and forcing the UI create these keys from the config. The long list of parameters is a bit ugly. Normally I'd suggest to put them into a struct, which could be extended without changing the API, which would allow extending it without having to change UIs. Except in this case UIs *have* to be changed when we add a new key: if the key is used, then the UI must not ignore it. Normally I prefer to make API changes in such a way that old code doesn't even compile, which is an argument in favor of the long parameter list. This doesn't work here, because we have a default implementation of these virtual methods and old code with the old function signature simply won't be called. Therefore I prefer the struct approach after all. Thoughts?

> > Much better, but I think the handling of all passwords should be implemented > > before merging it. > I think it should be the handling design issues for all passwords. Not actually > implementation, right? The implementation would be nice, too. We got away in the sync-ui with incomplete password support because it is meant to be used in situations where only one password is needed, but the command line as the fallback for the other situations should better be complete.

There's another issue here: properties can be added by backends dynamically. Therefore the list of passwords that the UI's savePassword() is called for shouldn't be fixed. For askPassword() this is handled by reading all properties, which triggers askPassword(). We should do something similar for savePassword() and call it "preFlush()", or something like that, because it might be used for other checks besides storing passwords in a keyring.