KF5 kwallet, kwalletd and wallet manager questions

[Valentin Rusu]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130825/6b62f350/attachment-0001.sig>