Design idea: Password stores
Note: some changes have recently happened. Like the TnyPasswordGetter type (and its default implementations, TnyGtkPasswordDialog and TnyGnomeKeyringPasswordGetter)
Linked
This documentation is one on one linked with the asynchronous connecting while dealing with ui calls page.
About
Right now the developer must set a get_pass_func and a forget_pass_func for each TnyAccount created in the TnyAccountStore implementation.
In other words, each time the developer implements a TnyAccountStore, he must also implement (in C, because it's a function pointer which is hard to get-right in language bindings) those two functions. Usually using a password store like the GNOME Keyring infrastructure.
The idea
The design idea is to have an interface for this like TnyPasswordStore and simple set it as a strategy-like instance of an account.
The type would have two methods to implement: to get a password, and to forget a password (for example in case it was wrong). Just like the two function pointers of TnyAccount, but then encapsulated into a new interface for this.
The idea behind it is that storing the password is not the task of the account itself, but the task of a password store. Like the GNOME Keyring infrastructure.
Benefits
- Makes it possible to support multiple password store infrastructures
- Removes the UGLY ifdef/else/endif compiler crap in the current TnyAccountStore implementations
- Makes it much more easy to support this in language bindings (auto generated usually)
Drawbacks
- Introduces a new library for each password store (libtinymail-gnome-keyring) (is this a real draw-back?)
- A little bit more complex in C (is this true? IMO it's subjective at least)
