[Ksecretservice-devel] Fwd: Re: KWallet/KSecretsService & GIT workflow

[Valentin Rusu]

Hello,

In the move to the new KSecretsService infrastructure (see the mail
exchange below) I need to modifiy the code of kdeutils/kwallet. In fact
I already started this :-)

kdeutils is not yet in KDE GIT and in Randa we discussed the
modularization of KDE. What are the current plans about it?

The kdeutils/kwallet module uses kde-runtime/kwalletd. By analogy,
kdeutils/kwallet may be better placed, in my opinion, inside
kde-baseapps module (and btw this module already moved to GIT).

Alternatively, we may consider creating a small module named
KDE/kdebase/kwalletmanager and move the kdeutils/kwallet code inside
this module.

Valentin

-------- Original Message --------
Subject: 	Re: [Ksecretservice-devel] KWallet/KSecretsService & GIT workflow
Date: 	Thu, 04 Aug 2011 12:17:36 +0200
From: 	Valentin Rusu <kde at rusu.info>
Reply-To: 	People working on ksecretservice <ksecretservice-devel at kde.org>
To: 	kde-core-devel at kde.org
CC: 	Sebastian Kügler <sebas at kde.org>, People working on ksecretservice
<ksecretservice-devel at kde.org>



Hello Sebas :-)

On 08/04/2011 09:51 AM, Sebastian Kügler wrote:
> Hi Valentino,
>
> [snip]
>> One more component should be the KWallet backend, an implementation of
>> the current KWallet class based on the new "Client API". KWallet code is
>> actually spread inside several GIT repositories: kdelibs, kdeutils and
>> kde-runtime. I think that I should do a branch named "ksecretsservice"
>> inside each of these repositories, then start using the new "Client API"
>> and do the switch to the new infrastructure. When this might become
>> "showable", I might push these branches to each of thses repositories,
>> along with an appropriate announcement to this list.
>>
>> Any thoughts about this process? How does it fit with current kdelibs
>> modularization process?
> How would the switch work, is it runtime-choosable, compile-time, or do you 
> need to change the code from kwallet to ksecretservice, so there's not other 
> means to go back, short of reverting?
I plan to let the existing code in place and switch in the new code by
the means of a runtime variable.
This variable will default to the new code when not defined in the rc
file. That would allow people to get back to old kwallet in the (very
unlikely indeed ;-) ) case where the new code would encounter a severe
bug when in "production".
A release or two later, when bugs.kde.org show that new code works
nicely, then I'll remove the old wallet code.

The secret service daemon has a piece of code that detects existing
wallets and, if the right command-line switch is given, starts importing
them. But at the time of the release I think I'll deactivate the
command-line switch requirement and let the daemon automatically import
wallets, then mark them as imported in it's own storage. This way,
passwords will get in secret service and the wallet clients will
seamlessly continue to work.

That would be the critical stage on the path to secret service switch.
Once applications function correctly with the KWallet API on
KSecretsService backend, the process of migration to KSecretsService
client API may start.

The introduction of the new daemon and API will also be accompanied by
an announce inviting application developers to start using this new API
instead of the obsolescent KWallet API. A compile warning will also be
added at that time.

As such, there will be a lapse of time where new applications will use
the new API and existing applications will still use KWallet API. I know
that Telepathy will be one of the first clients of the new client API.
> This question does affect how we introduce ksecretservice all over KDE.
>
> Cheer, and thanks for your work on ksecretservice!
Welcome :-)

_______________________________________________
Ksecretservice-devel mailing list
Ksecretservice-devel at kde.org
https://mail.kde.org/mailman/listinfo/ksecretservice-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/ksecretservice-devel/attachments/20110806/74f3415e/attachment-0001.html>