[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Configuring encrypted password caching: API proposal

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 17 Oct 2008 00:32:16 +0100

On Thu, Oct 16, 2008 at 09:17:38AM -0700, David James wrote:
> Right now, our API for configuring encrypted password caching is
> rather difficult to use. Right now, user applications which want to
> use encrypted password stores must configure their application to load
> different libraries and call different functions depending on what
> password stores are available. I think that we should simplify our API
> so that users can use encrypted password stores without writing their
> own code to dynamically load the appropriate libraries.
>
> The simplest possible API for loading encrypted password stores would
> be an API that simply allowed users to specify the type of the
> provider they want, and then we would return the provider if it is
> available.

> Thoughts?

Sounds like a great idea to me.

What types of providers do you have in mind exactly?

Do you want users to be able to say e.g. "I want KDEWallet"?
If so, I'd rather not call it a 'type', but just a 'name' for
the provider.

But maybe users would rather like to ask for things like: "I really
want a provider which will encrypt the password." Or: "I want a provider
which either encrypts the password or saves it in plaintext with
the user's consent" (this would currently match any available one).

This is fairly high-level, but given that you want to abstract
from system details, this would make sense, wouldn't it?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-17 01:34:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.