kwallet and QCA
kevin.krammer at gmx.at
Wed Jun 4 19:07:18 BST 2008
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
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
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel