kwallet and QCA

[Kevin Krammer]

On Wednesday 11 June 2008, nf2 wrote:
> Kevin Krammer wrote:

> > Sarcasm aside, I think that the limitation Nobert refers to is the scope
> > of out-of-process functionality.
> > Regarding the thread content, single-sign-on/authentifcation service this
> > is obviously not a problem,
>
> This might be a overhasty conclusion though. Keyring - for instance -
> seems to require direct socket connections.

Hmm, I am afraid I don't understand that this would make any difference.
So Keyring has a D-Bus based control connection and a custom protocol based 
data connection.
Assuming there is a reason why this approach is used, e.g. not transporting 
sensitive information over D-Bus or whatever, I don't see any problem.
Socket communication is part of our technology stack, in fact we already do 
use it for some of our infrastructure (e.g. IO slaves).

> > however it might be in a different context where
> > functionality needs to be provided in-process.
>
> Yes - and don't forget that even code being developed for out-of-process
> services could be reused in-process.

Sure, there is always possibility for reusing stuff. It is a bonus though, not 
a requirement.

> > Fortunately we see a move into service based infrastructure from
> > basically all desktop platform providers, so each software stack can
> > provide the kind of protocol implementation that makes most sense within
> > the concepts the developer of the respectice stack are used to (e.g.
> > threaded I/O on stacks like Java vs. event loop based I/O on stacks like
> > GLib/GObject or Qt)
>
> This sounds all very nice in theory, but i doubt that the "lack (or
> fragmentation) of platform" problem will ever be fixed that way. Maybe i
> am impatient, but i got the impression that this DAPI model just doesn't
> seem to be very successful in practice.

Not sure why you are referring to DAPI, I am referring to the service based 
infrastructure of desktop projects like GNOME and KDE, which at least on the 
KDE side has worked nicely for years, so I have no reason to believe it did 
not work for GNOME.

The service oriented approach (I apologize for the buzzwords) also works 
nicely for desktop<->system interaction, giving us a good overall desktop 
experience without sacrifising Unix goodies like multi user machines.

> Perhaps that's because it's 
> putting the cart before the donkey. Things need to be coded, and during
> this process the APIs and interfaces start to consolidate. Therefore the
> first thing necessary for collaboration is a decision on a standard
> programming language, library stack and maybe API style for this layer.

Yes, of course! Which is why shared service are such a nice thing since it 
avoids having to mix language, library stack or API style.

As a good example we can look at D-Bus, where it allowed managed code 
environment like Java and Mono to use it without having to do tons of 
managed<->native code bridging.

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/20080611/f8a68144/attachment.sig>