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)
