This starts to become a dangerous path (Was: New Feature for kdelibs)
kde at rusu.info
Tue Nov 15 21:33:22 GMT 2011
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 Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)
More information about the kde-core-devel