[proposal] KSecretsService components moving from playground

[Valentin Rusu]

On 10/16/2011 03:30 PM, Will Stephenson wrote:
> On Wednesday 12 October 2011 00:24:00 Valentin Rusu wrote:
>> Any thoughts?
> This all sounds good.  A couple of questions:
> 1) Are the KWallet API changes additions, or will some parts of the kwallet
> api be deprecated?  If so, when do you plan to add the deprecated tag?
The KWallet API will stay unchanged. However, some functions will behave 
slightly different, but the priority for me is to keep the API 
implementation change as consistent as possible with the legacy version. 
The deprecated tag will be added with future releases, when the new 
KSecretsService API will become more stable and *more importantly* 
documented.
> 2) When and how is migration performed under this model? When the checkbox is
> changed?
It's you that do check the box then click apply. From that moment on, 
the KWallet API in newly started applications will go through the 
KSecretsService API in kdelibs. Already running applications still use 
kwalletd, until session is restarted.
> Does this handle cases where a wallet request is already showing (on
> another desktop, for example) or when a wallet request comes in during the
> migration process?
I think the above explanation answers this. To be more precise, the 
application that is already prompting for the password will get it's 
secrets from kwalletd.
> 3) When is migration performed during a mandatory migration? Is there a chance
> that migration will cause login to block?
KDE session login? There is no incidence on that.
The migration will become mandatory with some previous release, when 
decision will be made to drop kwalletd.

Valentin

-- 
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)