On 08/25/2013 12:39 PM, Kevin Krammer wrote: > On Sunday, 2013-08-25, Valentin Rusu wrote: >> On 08/24/2013 02:32 PM, Kevin Krammer wrote: >>> On Saturday, 2013-08-24, Albert Astals Cid wrote: >>>> El Dissabte, 24 d'agost de 2013, a les 12:31:20, Valentin Rusu va > escriure: >>>>> * AFAIK, frameworks should be independent and self-contained. kwallet >>>>> depends on kde-runtime/kwalletd. This component should be detached from >>>>> kde-runtime sources and attached inside kwallet/src/kwalletd, >>>>> preserving history if possible. I can handle this task if that's OK >>>>> for you (Aron, David, Kevin?) >>>> >>>> This makes sense and AFAIK is what is intended with frameworks, i.e. if >>>> a lib needs a binary, that binary and the lib should be shipped >>>> together >>> >>> One thing that could be put into consideration is whether the library/API >>> would work with any SecretService implementation or require kwalletd >>> specifically. >> >> The kwallet API is only implemented by kwalletd AFAIK. So for this API's >> cas, we should provide kwalletd along with it. >> >> The new secret service API, on the other hand, is likely to have several >> implementation. In that cas, the daemon should not be systematically >> tied-in. > > Ah, I see. I thought that the KDE client API for secret service would > currently be part of that framework, but of course if it is separate than > that > is even better. > The LXDE folks are looking into secure storage and currently seem to consider > gnome-keyring as the daemon, so having a ready Qt API without runtime > dependencies would certainly be of interest to them. > >> I think that future versions of the kwallet framework will have >> configure options, to let packagers/users choose what to install. > > Right, makes sense. I was mostly concerned about the Secret Service part > which > I mistakingly thought was part of the kwallet framework dicussed here.
Well, I actually intend to add secret service API to our good old kwalletd. As such, it'll be able to offer it's services via kwallet.h API or via the newer specification.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
