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

List:       kmail-devel
Subject:    Re: PGP 2 support
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-10-30 18:08:24
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

KMail
 | loads
 v
KDE-specific plugin container plugin
 | loads
 v
generic Sphinx plugin
 | is based on
 v
gpgme
 | calls
 v
GnuPG

I surely hope the "generic Sphinx plugin" _is_ 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???). Come 
on, that's nonsensical. 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).

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

My idea of the set of plugins is the following:

1. Define the interface for the crypto core functionality (in C++, of 
course). Ie. a wrapper around gpgme resp. kpgp

2. make a registry (factory) of available crypto plugins that takes the 
headers of the multipart/{encrypted,signed} body part (ie. the 
content-type one, resp. whether it's "encrypted" or "signed" and the 
value of the "protocol" parameter) and tries to instantate a fitting 
crypto context, which implements (1) and offers verify/decrypt and 
signencrypt routines, each given the relevant bodies (and - if needed: 
headers) of the {two nested,to-be-processed} body part(s) as 
parameters. This factory needs only be a QDict<createFunction> or 
something like that.

3. Define objects for meta data that needs to be passed to or from 
higher levels. A Qt wrapper of a C++ wrapper of the gpgme "objects" 
would do the job, I think.

4. define interfaces for and implement configuration and key management 
plugins (GUI plugins). They store the config in KConfig's from where it 
is read by (1,2).

Marc

- -- 
An der Prioritätenskala wehrhafter Demokratien gibt es nichts zu  
deuteln: Erst kommt die Stärke, dann Freiheit Hand in Hand mit der  
Gerechtigkeit und in der Nachhut trottet der Frieden hinterher.
- -- Goedart Palm "Der Friedensnobelpreis und ein bisschen Krieg"
   Telepolis 2001/10/13 (#9807)  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE73v+f3oWD+L2/6DgRAtHYAJ4sK49PSZBdxIsS7BECRy0Ez6+jqwCfUTNd
RsbUV081tRjSipa96rSzhd0=
=WFtM
-----END PGP SIGNATURE-----


_______________________________________________
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]