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

[Matt Rogers]

Hi,

On Sunday 19 September 2004 04:28 pm, Brad Hards wrote:
> FYI. Any thoughts or comments?
>

yup, spread throughout the email. ;)

> 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?
>

I imagine it would be possible, although i'm not in charge of that. :) 

> 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.
>

I'm sure this would be fairly easy to control, especially if QCA is imported 
into kdesupport.

> > > (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).
>

We like incremental development around here. :) I would definately go with the 
adding pieces approach. just my 2 cents.

> > 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.
>

My "idea" for the import of QCA would be something along the lines of this:

We import it into kdesupport. This will make it easier to keep the things from 
happening to it that we don't want to happen to it, namely keeping it 
cross-platform compatible. It will also allow you to do seperate releases, 
etc. since the kdesupport module doesn't follow the normal kde release 
schedule rules

Maybe some API documentation will get added. Brad seems to be a master at 
that.  

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

In short, I and a few other people who i won't completely vouch for, want to 
see this library be used by kde, and if we can give it a permanent home, even 
better. QCA will also allow us to do a bunch of other things with our crypto 
layer that we couldn't do before, and i'm quite excited about getting it 
imported into kde cvs (finally).

Thanks,
Matt