Fwd: Re: [Delta] [patch] Additional hash functions for QCA

[Brad Hards]

FYI. Any thoughts or comments?

Brad

----------  Forwarded Message  ----------

Subject: Re: [Delta] [patch]  Additional hash functions for QCA
Date: Mon, 20 Sep 2004 07:18 am
From: Justin Karneges <justin-psi at affinix.com>
To: Brad Hards <bradh at frogmouth.net>
Cc: delta-affinix.com at lists.affinix.com

On Sunday 19 September 2004 03:48 am, Brad Hards wrote:
> On Sun, 19 Sep 2004 17:14 pm, Justin Karneges wrote:
> > > Alternatively, I know that some KDE guys have previously expressed some
> > > interest in importing QCA into their (our) CVS tree. Would that work
> > > better for you?
> >
> > Sure, you might want to do that temporarily, and then I can merge things
> > back later.  However, I definitely don't want a permanent fork, as that
> > would undermine the efforts of promoting QCA as a common library.
>
> The only use of it would be if QCA moved (ie. not forked). KDE currently
> has two copies of QCA imported into it (one for Kopete, and another in
> kdenonbeta/jabberservices). KOffice is going to be the next user.
>
> The goal would be to have QCA as a first class citizen within KDE, but also
> available (ie packaged separately) for other users outside of KDE. We do
> have a case like this already, for TagLib ( see
> http://developer.kde.org/~wheeler/taglib.html ).

This could be good.  I already had wanted to find a real home for QCA.  Would
it also be possible for KDE to host the website?

My main concern is to keep QCA cross-platform and shared with non-KDE apps.
Anyone who might commit to the code needs to ensure that they don't break
Windows compatibility, and there should definitely not be any sort of KDE
code in there, #ifdef or not.

> > (and actually, reading any of the May/June QCA stuff from the list
> > archive would probably be a good idea).
>
> I've read through, but my goals are less ambitious. I just need a little
> bit of SHA-1, Blowfish and the RFC2898 key derivation, then I'm happy.
>
> WARNING: Uninformed opinion follows:
> QCA 2.0 is looking like a big job. I think you might be better off evolving
> QCA 1.0 rather than going for such a mammoth rewrite. That evolution allows
> you to recruit people to help you, which is much more difficult when you
> have a big change.

Good point, I'll see if maybe I can add pieces at first (like the util
classes).

> I'm happy to help out with the unittests, with API doco, and with easy
> add-ons (like the extra hashes), but it is hard to help out when you are
> just beginning to get involved, and there are a lot of unknown changes to
> come.

Probably the best move would be to migrate to KDE CVS, and then let you guys
go hog wild with docs, extras, etc.  You'll effectively be the maintainers.

Later this year I can start slowly importing my newer API code as it is
 ready.

-Justin

-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040920/f200dfca/attachment.sig>