Hello, KSecretsService API is now nearing the finished state. But this would be confirmed by starting using it as a KWallet API backend. Naturally, I'll do this on my system but I'd like to do it such that: - allow for current kdelibs modularization efforts, - allow volunteers to test this new feature, - ease the "playground to kdereview to kde-???" process, - easy merging to master when code become stable enough.
KSecretsService is intended to supersede the KWallet infrastructure. It's structured in several modules: - Client API -- intended for KDE applications as a KWallet API replacement; behind the scenes it's using DBus to call the deamon, but that's an implementation detail, - Daemon -- implementing a DBus freedesktop.org specification (see [1]) and doing the actual secret management on disk (and hopefully on smartcards), - SecretSync tool -- intended to allow secrets synchronization among several devices. All these modules now live together inside one playground GIT repository [2]. 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? [1] http://specs.freedesktop.org/secret-service/ [2] https://projects.kde.org/projects/playground/base/ksecretservice _______________________________________________ Ksecretservice-devel mailing list Ksecretservice-devel@kde.org https://mail.kde.org/mailman/listinfo/ksecretservice-devel
