kwallet and QCA

[Aaron J. Seigo]

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.

the dictionary defines it as "enough to meet the needs of a situation or a 
proposed end". don't read into words what i'm not saying =)

> I'm afraid it's not. It makes the whole system more complex,

it doesn't make the individual desktop stacks more complex, however.

> takes ages to formulate and implement (twice) and after

of course, we already have implemented these things twice. *shrug*

> all has no advantages compared to just adopting and improving *one*
> existing implementation.

there are scenarios where adopting an implementation and improving it is the 
better option, and scenarios where it isn't.

it is impossible to have this discussion in vague terms and have any 
meaningful outcome. so let's just not =)

instead, let's discuss specifics scenarios. in this case the idea of adopting 
libgnome-keyring. having looked at it, the api is really horrid (though 
presumably that would be "fixed" by an API layer on top of it) and it seems to 
offer only a subset of kwallet's features.

the API bit is concerning due to the feature subset issue: improving it would 
mean both getting buy in from the libgnome-keyring developers (have you talked 
to them at all about this?) and dealing with that API (not fun)

simply saying "we can wrap libs!" is not a substitute for actually having a 
good relationship with the development team of the libraries in question and 
feeling confident in our ability to work on those libs over the long term.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080604/5a98c2f5/attachment.sig>