Proposal for a Desktop Neutral Crypto API

[Marc Mutz]

On Thursday 07 April 2005 10:26, Nate Nielsen wrote:
<snip>
> Nothing is wrong with GPGME. Seahorse uses it extensively. In fact most
> implementors of this API would use GPGME. This API one level above
> GPGME, at the user interface and high level object level, and allow us
> to do things (ease of use, ui consintency, etc...) that are difficult at
> a low level.
<snip>

Such as?

You need to explain to me how such a level could possibly be made independant 
of the GUI toolkit used. You know, the next level above gpgme in my design is 
the Qt event loop integration, which, as the name suggests, already includes 
the Qt dependency (ok, there's gpgme++, but that's just C++ bindings for 
gpgme). The then-next level is Kleo::Job, which is an interface that uses the 
Job (Command) pattern to perform stuff asynchronously (encrypt, decrypt, list 
keys), etc. That one already links to kdeui, because, as you propose, it 
provides reusable UI elements for crypto operations.

I fail to see where an additional layer between (e.g.) Kleo::Job and gpgme 
could fit in, please enlighten me. It could just be a duplication of gpgme's 
API with the goal of allowing other backends than gpgme. But guess what: 
gpgme allows this already (not conveniently, but certainly interface-wise).

Oh, and gpgme just turned LGPL in v1.0.2, if it's GPL'ness was of any concern 
to anyone. Maybe we can count Evolution among the gpgme users soon.

Still not convinced,
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050407/15a9139a/attachment.pgp