[Authentication] On Compatibility and Features
Stef Walter
stef-list at memberwebs.com
Wed Jul 15 10:03:51 PDT 2009
Before commenting on the various posts that have been made about
different features...
We need to challenge each feature and see if it can't be implemented on
the client side and whether it needs to be in the API.
If each participant tries to mandate their current set of features into
this API we'll have a mess (at best) or unimplementable (at worst).
A good example is the format of the secrets:
* Currently gnome-keyring only supports UTF-8 encoded secrets. It
actively goes out of it's way to reject any keyring that has a
secret that isn't UTF-8.
* KDE Wallet can store secrets in three formats (binary, string,
dictionary).
Obviously if we each mandate our compatibility/feature without earnestly
looking for a compatible work around, then we cannot have a common API.
The current draft of the secrets API does not model gnome-keyring's way
of doing things. gnome-keyring's current model is old and crufty in many
ways. Much of it originated from before my maintainership, but I added
some of the cruft too.
This secrets API differs in at least 10 to 15 different respects from
gnome-keyring. These changes are sometimes incompatible with the current
gnome-keyring, but I believe each one is a necessary compromise to
achieve a viable cross desktop API.
There'll be a good deal of challenging each other's requirements, and
making sure that they really are absolutely necessary. In many cases
we'll need to compromise and find ways to map our current feature set
into the new API whenever possible.
Cheers,
Stef
More information about the Authentication
mailing list