On Friday 14 June 2013 20:46:04 Kevin Krammer wrote: > On Friday, 2013-06-14, Pali Rohár wrote: > > I think that QtKeychain is still young project, there could > > be packaging problems and my goal is to have kwallet > > support. > > It has been around for quite some time (~2 years) and it has > KWallet support. > > > So I think using stable kwallet library will be better for > > now. Kwallet code will be in separate plugin, which means > > it will be possible to create QtKeychain plugin later > > without problems. > > One thing to understand when it comes to KWallet is that KDE > will transition to the freedesktop.org Secret Service API at > some point, keeping KWallet's API for compatibility, but > being capable of using any Secret Service daemon > implementation. > > Thus using an abstraction like QtKeychain, which has already > proven to be able to abstract KWallet and the Mac OS X > Keychain is likely to be adaptable to the Secret Service > system as well, potentially making it transparent when the > switch happens. > > The Secret Service API is, IIRC, already provided by GNOME's > secure storage service gnome-keyring. > > Cheers, > Kevin
Ok, so if I choose QtKeychain for implementing gsoc kwallet support, there could be problem with packaging. But benefit is support for Apple & Gnome. If I choose kwallet library directly, there will be no packaging problems, but it does not support Gnome secure storage yet. But in future there could be one. There could be another problem with QtKeychain library. Similar to contacts. If user change desktop QtKeychain can use another password storage (e.g kwallet is not running but secure storage yes). -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.