This starts to become a dangerous path (Was: New Feature for kdelibs)

[Valentin Rusu]

On 11/15/2011 10:16 PM, Alexander Neundorf wrote:
>> "Minimizing the impact" means to align up- and downstream, ie. find
>> a way to provide features *now* w/o really opening kdelibs to new
>> features but at best accelerate frameworks development.
>> (as you probably read in the rest and unfortunately not commented part
>> of my original post)
> Hmm. AFAIK we have currently two cases. One is SecretService and the other one
> is something with cookies or so.
>
> How about "it is ok to add it to kdelibs if it is also added to frameworks" or
> something like this ?
> This would also be very different from "kdelibs is open".
>
> I fully understand that it makes a lof ot sense to feature freeze kdelibs for
> the frameworks effort in general.
>
> But nevertheless I don't see what the bad impact of allowing secretservice to
> go into kdelibs now would have, assuming Valentin ports it also to frameworks.
Well, I just removed ksecretsservice from kdelibs and kderuntime (see 
latest mails exchanged with Kevin and Aaron). The code specific to it in 
KWallet is inactivated.
After the release, KWallet  code will have a plug-in support, loading if 
found the ksecretsservice daemon.
And for me this infrastructure was intended from the beginning to go 
inside the frameworks.

Valentin

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