kwallet and QCA

[Kevin Krammer]

On Tuesday 03 June 2008, Robert Knight wrote:
> > This is a common mistake, intriguingly often happening in discussions
> > around free software desktop implementation sharing.
>
> Do you mean that it is not a good idea or that it should have been done
> earlier?

I meant that concentrating on something as totally unnecessary as a shared 
client library will stall the tremendously useful convergence of 
authentification stores.

Fact is that there are at least two capable authentification stores, both 
offering their functionality to clients via D-Bus.

A common connection name, a couple of common object paths plus respective 
interface would probably be almost trivial to add to both, instantly allowing 
third party application to use these interfaces.

Mozilla could implement a little helper process based on their authentication 
store technology so they have a fallback in window manager only environments, 
etc.

I am getting the impression that I somehow misunderstood the "single shared 
library" concept you wrote about.
Is this for accessing on-disk authentification data in cases where users 
switch environments?

Cheers,
Kevin

>
> Regards,
> Robert.
>
> On Tue, 2008-06-03 at 20:09 +0200, Kevin Krammer wrote:
> > On Tuesday 03 June 2008, Robert Knight wrote:
> > > Hi,
> > >
> > > This doesn't answer your question directly but something that came up
> > > at FOSSCamp during the KDE/Gnome collaboration session and which also
> > > relates to upcoming specifications in Ubuntu and Fedora for
> > > single-sign-on* is that it would be useful to share the password
> > > management storage, API and/or code between gnome, KDE, Firefox,
> > > OpenOffice etc.  I don't know whether OpenSuSE are planning anything in
> > > this area.
> > >
> > > Since this is not particularly exciting stuff I think it was suggested
> > > that a single shared library could be used to do all of the backend
> > > work.
> >
> > This is a common mistake, intriguingly often happening in discussions
> > around free software desktop implementation sharing.
> >
> > In any case the single-sign-on will be implemented through a desktop
> > service, , e.g. gnome-key-ring, kwallet module in kded, etc., which means
> > it will have to have a well defined IPC API anyway, most likely D-Bus
> > interfaces.
> >
> > Which also has the nice side effect that it can be implemented right
> > away, i.e. as a second interface to already existing key storage
> > solutions without needing to simultaniously transition all applications
> > using the desktop specific interface right now.
> >
> > > Unfortunately since QCA depends on Qt, I guess that might be a
> > > hard-sell as one of the dependencies.
> >
> > It would be a dependency of one service implementation, an implementation
> > detail, so definitely not a problem in this context.
> >
> > Cheers,
> > Kevin


-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080603/154b9afe/attachment.sig>