On Thu, Oct 16, 2008 at 4:32 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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?
I want to allow users to be able to select the same providers they can
do now with the current approach. In the case of kwallet, there are
actually two providers: kwallet_simple_provider, and
kwallet_ssl_client_cert_pw_provider. In my API proposal, users would
be able to select these providers separately. Users who want both
providers would need to ask for each provider in a separate function
call.
My new API offers two benefits:
1. Users don't need to implement conditional library loading
2. Users don't need to use #ifdef inside their code to avoid
compilation errors.
3. Users only need to learn about one function, and can store a list
of their providers in a simple array without needing function
pointers.
As you point out, it would also be nice to have a policy-based API. I
think that we should first build a low-level API for selecting precise
providers and then build a policy-based API on top of that low-level
API. This would give users maximum flexibility, so that they can
perhaps implement use cases that we did not think about in our design
of the policy-based API.
At this point, the need for a low-level API which abstracts the
"library loading" issue is a rather urgent one, because it is rather
difficult for users to use our API if every user has to implement some
form of conditional library loading. Once we have this low-level API,
I think it would be useful to eventually build a policy-based API as
well. Note that a policy-based API would need to map a single policy
to an ordered list of providers.
Cheers,
David
---------------------------------------------------------------------
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 19:49:18 CEST