Various design questions

[George Staikos]

On Sunday 21 October 2001 07:43, Markus Montkowski wrote:

> > > I still think there should be one small repository
> > > which is GUI and big-library independent. It just does not make
> > > sense for each GUI framework to have its own in the long run.
> >
> >    If it doesn't require one to link GPG libraries into the app in order
> > to access the database, and if it's easy to obtain all forms of
> > certificates needed for S/MIME and SSL (signers, clients and servers),
> > then yes this is certainly desirable.  Also we need the ability to store
> > entire certificate chains.  Right now I use K[Simple]Config because it's
> > easy and it's standard in KDE.
> >
> >    However I must warn that I no time available to modify the KSSL code
> > to make use of a different library any time in the near future.  The code
> > in KSSL is ugly, mostly due to trying to merge KDE with OpenSSL (not a
> > fun task in the least!).
>
> Hmm this sounds realy ugly don't know the Kx stuff since I'm running a
> Gnome desktop,
> but wouldn't the best approach be to keep the management and the GUI appart
> from each other
> and use Dynamic runtime linking? Each Module should export some well
> defined Functions like

   This is advocating having two implementations of the exact same code.  At 
that point one might as well implement S/MIME using KSSL/OpenSSL.

> - Init(PFNTAB pCallbacks, PINFO pModInfo)
>    Called on Init with a Table of Callbacks for GUI stuff like MsgBoxes,
> Statusbars, maybe if needed even a
>    Dialog function to handle some XML defined Dialog Templates. Returns a
> structure with the a short and
>    a long name of the  module, version etc.
> - Destroy() Called when ending access.
> - GetVersion(ULONG pulVersion) Returns the Implemented Interface version
> for backward compatibility.
> - Command(ULONG ulCtx, ULONG ulCommand, ULONG ulParam1, ULONG ulParam2)
>    Used for all the management calls etc.

  Well I have to say that this is a terribly ugly interface from a KDE 
perspective.  And it's even more work to implement than what I suggested, I 
think.

> The Management app would simply have config page where you can add the
> modules to use.
> All the key DBs are shown in a Treeview like control. If you are at the
> root of all DBs you would import
> a key to all if you selected 1 or multiple specific DBs you would add only
> to these.

    Ok but from this point of view, it will still have to have multiple 
backends.  So now we have this:

--+
   |
   +----  KDE Certificate Database
   |                +--  Cert X
   |                +--  Cert Y
   |                +--  Cert Z
   +----  Aegypten Certificate Database
   |                +--  Cert X
   |                +--  Cert Y

And they both contain the same certificates in most cases, they both do the 
same thing, yet different apps use different ones.  I'm certain that the 
"newbie" user will by default import his certificate into the KDE database.  
We will get enough bug reports for this.

We have worked long and hard for consistency in KDE.  I don't want to see 
this inconsistency happening, and as I said, I certainly won't be coding 
support for something like this any time in the near future.


-- 

George Staikos