ksecretservice (Re: [Kde-cvs-announce] KDE SC 4.8 Soft Feature Freeze)

[Aaron J. Seigo]

On Monday, October 31, 2011 14:15:40 David Faure wrote:
> On Monday 31 October 2011 13:16:26 Sebastian Kügler wrote:
> > On Monday, October 31, 2011 13:01:27 Allen Winter wrote:
> > > I'm of the opinion that KSecretService can be released with kdelibs 4.8
> > > as long as it passes review.
> > > 
> > > What do others think?
> > 
> > If we're doing a 4.8, we should allow features in. Having too much stuff
> > pending only for Frameworks5 (which we don't have a date for yet), will
> > cause bitrot, frustrate developers and make it harder to advance the whole
> > of KDE SC before Qt5 and Frameworks5 are out.

let's not repeat the 3.4/3.5/4.0 history all over again. these are the same 
argument we saw then, and we know what they ended up contributing to: a really 
nice 3.5 release and a very delayed 4.0 that did not achieve its potential.

> But on the other hand changing the whole implementation behind KWallet is a
> big change. The kind of change that belongs to KDE Frameworks 5 in my
> opinion, especially since it comes with "some changes in API behavior",
> which app developers expect in a '5' release, but not in a '4.8' release.

agreed .. but there may be ways around this.

> It also makes a lot more sense to consider the whole thing as one separate 
> framework, 

i agree again. in fact, it would be _great_ if KSS could be released in its 
own repository now (to be picked up into the Frameworks meta 
module/build/whatever later) with KWallet built with KSS in the backend if KSS 
is already installed.

so the first question is: what are the dependencies of KSecretsService? from a 
quick grep of the includes, they are:

* KDebug
* KLocalizedString
* KToolInvocation
* KJob
* KCompositeJob

all of which live in libkdecore .. so at least there are no dependency crazies 
in there... of the above classes, only the use of KDebug and KToolInvocation 
(with some minor but still unfortunate copy and paste) could be easily taken 
out. so the dependency on kdecore is probably there to stay.

which leaves us with a dependency between KWallet in kdeui and 
KSecretsService. looking at kwallet.cpp, with KSS it has become:

rv KWallet::someMethod(.. signature ..)
{
     if (walletLauncher->m_useKSecretsService) {
         ... secrets service path ...
     } else  {
         ... old code ...
    }
}

with a little bit of work, KWallet could be made to use a pluggable backend 
(with private API; we don't need anything fancy here) and KSecretService could 
ship with that backend and KWallet could use it if it exists. this opens up 
possible security issues, however. (not that they don't already exist with 
KWallet ...) 

the reason for exploring this is that it would be nice if application 
developers could start moving to KSS and our users could start using KSS 
without KSS becoming "part of" kdelibs 4.[78].

if kdecore came in its own tarball already, this would be easily solved. 
that's not an option, i know, so i wonder if there is some other way of doing 
this.

throwing whole new libraries in kdelibs now though is, imho, simply not a 
viable option.


as an aside: i'm a little concerned with calls such as these:

qRegisterMetaType<SecretStruct>();

which do not include the namespace; i seem to recall having issues in certain 
places in Plasma where these meta type registrations required the use of the 
namespace so that code that did variant.value<KSecretsSevice::SecretStruct>() 
would still work properly as expected. perhaps i'm mis-remembering here, but 
this should be checked into before we ship it... 

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20111031/0dfb9824/attachment.sig>