[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: PGP 2 support
From:       Karl-Heinz Zimmer <khz () kde ! org>
Date:       2001-10-30 19:06:36
[Download RAW message or body]

On Tuesday 30 October 2001 20:29, Marc Mutz wrote:
> On Tuesday 30 October 2001 09:53, Karl-Heinz Zimmer wrote:
> <snip>
>
> > Ok, this would result in different "Plug-In Container"s for KMail,
> > for mutt, for KOffice ...
> >
> > These containers (being an integral part of the respective MUA (or
> > program, resp.)) are calling the independend Plug-In and they can
> > decide which part of the Plug-In's functions they wish to use...
>
> Ugh. I hope I understood you wrongly here: You don't propose a plugin
> that has a plugin interface, into which a plugin is plugged into that
> uses gpgme to interface to gnupg???

No, I don't propose that.  :-)


> KMail
>
>  | loads
>
>  v
> KDE-specific plugin container plugin

Things will be different: KMail will have the "Plug-In Container"
embedded as _integral_ part, it will not 'load' that.


>  | loads
>
>  v
> generic Sphinx plugin

That's correct.
Also the user might want to decide loading the old "PGP Plug-In" that
we are going to implement first.


>  | is based on
>
>  v
> gpgme
>
>  | calls
>
>  v
> GnuPG
>
> I surely hope the "generic Sphinx plugin" _is_ gpgme?

Please have a look here:
  http://www.gnupg.org/aegypten/images/module-overview.png

The "Gpg Plug-In" is directly links against GpgME - just see it
as an extention of GpgME.


> But reading mua-interation.sgml, I get the feeling that you want
> to build a generic Sphinx plugin (shared lib), which contains
> both cryptographic base functionality (in the form of - roughly
> - gpgme 0.23?) _and_ GUI elements (which are respresented in
> xml form???).

You got it.  Of course our Plug-In will not be a monolitic bloc
but consist of several parts that will be taken care of by the
main Plug-In module...

> Come on, that's nonsensical.

As you surely can imagine I don't like your theory that our concept
is 'nonsensical'.  We did think about that for _quite_ a while and
(at least in my not so humble opinion) it _does_ make sense.  ;-)


> The Qt/KDE based dialogs can easily be created natively for
> 1. mail specific
> 2. generic
> functionality. Those should be
                       ^^^^^^
> a. native dialogs
> b. two separate plugins (and plugins that are separated from the
> cryptographic core, ie. gpgme-as-is -now).


Sorry, I don't agree to you.

a) Frankly speaking: I do not accept your "should".

   I am not trying to tell you how you 'should' code your programs
   and I hope you agree to grant me the same freedom, a "should"
   does not help both of us.

b) Of course(!) all dialogs showing up when the "Gpg Plug-In"
   was accessed from within KMail _will_ be native KDE dialogs.

   We do not intend to bother you with strange looking dialogs
   but our dialogs will be absolutely system conform - respecting
   the user's style settings and so on. (Details will be published
   here in some days...)


> > Let me cite our "MUA Integration" specification:
> >
> > <quote>
> >     The Plugin Container has to be implemented once for each
> >     supported MUA. Since not only the internal workings of the
> >     MUAs, but also the programming languages used, differ greatly,
> >     it is unlikely that much code can be reused between the
> >     various MUA Plugin Containers.
> >
> >     The Plugin Container has the following tasks:
> >
> >     a) Locate the security plugins.
> >
> >     b) For each found plugin, resolve the specified functions to
> >        determine whether the plugin fulfills the plugin API.
> >
> >     c) For each found and accepted plugin, create a menu entry or
> >        something similar in the MUA. For example, a GUI MUA (like
> >        KMail) might create a submenu in a Security menu and even
> >        add a toolbar, as well as a section in its configuration
> >        dialog (or even a completely new dialog).
> >
> >     d) Load the current configuration settings for each plugin
> >        and fill internal state variables as necessary.
> >
> >     e) From the configuration information of the MUA, determine
> >        the currently active security plugin. If no such information
> >        is available, select one security plugin to be the active
> >        one in an unspecified way.
> >
> >     f) As needed, activate backend functionality like encrypting,
> >        checking certificates, etc
> > </quote>
>
> <snip>
>
> > This is our plan, don't you like it?  :))
>
> <snip>
>
> If this is all to be put into a single plugin, then no, I don't.

I am sure the above mentioned details (no monolitic bloc, true KDE
dialogs...) will make things look better for you.  :)

Now for some more good news: Our own concept is not toooo far away from
your proposal (so I hope you will like it finally) as we will build a
very flexible solution where a Plug-In does not neccessarily have to
provide all functionality that the Gpg Plug-In does...  (again: Details
to follow soon...)

Ciao,

  Karl-Heinz

-- 
Karl-Heinz Zimmer, Senior Software Engineer, Klarälvdalens Datakonsult AB
<mailto:khz@klaralvdalens-datakonsult.se>            <mailto:khz@kde.org>

   BugCops  ***  Making Free Software Better  ***  http://bugcops.org
_______________________________________________
kmail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]