?Two Certificate Managers? (Re: regarding KPF)

[George Staikos]

On April 20, 2002 03:43, Marc Mutz wrote:
> On Friday 19 April 2002 21:24, Waldo Bastian wrote:
> > On Friday 19 April 2002 06:19 am, Marc Mutz wrote:
> > > Of course we KDE people like to point out that the first mailer that
> > > has to be stuffed with S/MIME support is KMail. We like to see this as
> > > a KDE project. But it isn't. It is much more than just adding S/MIME to
> > > the random KDE mailer.
> >
> > If this isn't a KDE project then what it is this stuff doing in KDE CVS?
>
> <snip>
>
> Pardon? What you see in KDE's CVS is the KDE part of it.

   Yes but if it is a "KDE project", then it should follow KDE policy and use 
KDE facilities.  It should not duplicate code from the KDE libraries, let 
alone duplicate an entire KDE facility.  If it does not follow these 
guidelines, then it should not be in KDE CVS.

> KAddresbook has been amended with OpenLDAP support. This is already in
> head. Does anyone here want to say that it shouldn't? Waldo?

   It follows proper KDE development standards afaik.  I know that there was 
work done on the ldap code and they were very nice to try to make it work 
with TCPSlaveBase too.  Apparently it didn't work, and I'm not surprised.  In 
any case, this still follows proper KDE development models.

> KMail gets a new plugin mechanism for cryptographic plugins and some
> enhancements to body part handling. This will be merged into HEAD VSN.
> Again: Anyone here against having that in CVS???

   Funny, in September/October 2000 (IIRC) I made a patch to clean up the part 
handling and message representation code in KMail but no-one was interested.  
It's good to see this code go in.

   It is not good to see two certificate managers though.  At least, not good 
to have two X.509/PKCS managers.

> The cert management part was previously part of KMail's config dialog. i
> asked them to extract it into a stand-alone app since I think that it's out
> of scope for KMail proper.
> This part is in CVS since KMail/Aegypten will not really be useful without
> it, at least when using S/MIME. Consider it part of KMail.

   Then KMail is broken and should be fixed.

> Do you see gpgme, newpg, libgcrypt, libksba, dirmngr, pinentry, openSC or
> mutt anywhere in KDE's CVS?

  Of course not, that would be broken too.

> Can everyone please stop throwing uneducated guesses and FUD around,
> please? Thank you.

   These are not guesses, not uneducated, and not FUD.  I am stating that a 
service that duplicates functionality in kdelibs should not be in CVS.  
Perhaps this should be better documented on developer.kde.org.

See:
http://developer.kde.org/documentation/other/checklist.html
"make sure you aren't unknowingly duplicating an existing application"

For instance.

And no that doesn't mean that you can "knowingly duplicate an existing 
application" and it's ok just because it isn't "unknowingly".

I think we should make this more clear though.  If KDE doesn't provide a 
facility, then by all means implement it.  If KDE's facility is insufficient, 
tell the developers so something can be done (or perhaps a consensus can be 
reached on allowing the application to duplicate a facility), contribute to 
the KDE facility, or don't ship your code with KDE.  Not wanting to use the 
KDE facility is not sufficient.