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 <k...@rusu.info> Reply-To: People working on ksecretservice <ksecretservice-devel@kde.org> To: kde-core-de...@kde.org CC: Sebastian Kügler <se...@kde.org>, People working on ksecretservice <ksecretservice-devel@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@kde.org https://mail.kde.org/mailman/listinfo/ksecretservice-devel
_______________________________________________ Ksecretservice-devel mailing list Ksecretservice-devel@kde.org https://mail.kde.org/mailman/listinfo/ksecretservice-devel
