kwallet and QCA

[Kevin Krammer]

On Wednesday 04 June 2008, nf2 wrote:
> Aaron J. Seigo wrote:
> > On Tuesday 03 June 2008, Maksim Orlovich wrote:
> >> Sharing the file format would be sufficient.
> >
> > along with he implied shared location and locking mechanism, you're quite
> > right: that would be sufficient indeed.
>
> The word "sufficient" somehow suggests that this would be the easier and
> more realistic approach. I'm afraid it's not. It makes the whole system
> more complex, takes ages to formulate and implement (twice) and after
> all has no advantages compared to just adopting and improving *one*
> existing implementation.

One issue here is that this is about two separate problems.

One problem is the authentification service, the process a user 
authentificates against and with which then other processes exchange 
authentification requests. Basically a trustee of the users.

Since there are already capable implementations for that, it is a "low-hanging 
fruit" for interoperability, as I already described before.

The second problem is the persistant storage of the authentifaction data.
I agree that having a shared library for dealing with that uniformly would be 
benefitial, though there is still need for proper documentation of locations, 
formats and crypto algorithms involved.

A nice aspect of these two problem is that they are orthogonal, so they can 
but don't have to be tackled concurrently.

Lets say that the final goal is to have a single, probably cooperatively 
maintained, service implementation, then there are a couple of approaches to 
reach this goal.

One is to design and then write this ultimate solution from scratch, covering 
all use cases of all currently exisiting implementations, etc.
Evaluation all these use cases will take some time, though it is quite 
possible that doing this will really result in a great implementation. 
Drawback is that it takes longer until applications and therefore the users 
can actually use it.

Another one is to define a couple of milestones between now and the goal, 
where at each milestone something new fades in and something old fades out.
There will almost immediately be a noticable benefit for the users, they can 
even likely understand the progress along the road when additional 
improvements take effect.
The drawback is that none of the milestones will be an ideal implementation.

Regarding the interface, the two approaches differm mainly in when it has to 
be specified.
The first approach allows to postpone the interface definition to the the 
moment of release, while the second approach basically depends on it being 
available as the first milestone.

Fortunately there are way to detect capabilities of runtime dependencies, so 
in the worst case they can be tried in parallel if no agreement can be 
reached beforehand.

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/20080604/b2dc7820/attachment.sig>