Proposal for a Desktop Neutral Crypto API
mutz at kde.org
Thu Apr 7 11:25:01 EEST 2005
On Thursday 07 April 2005 10:26, Nate Nielsen wrote:
> 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.
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,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050407/15a9139a/attachment.pgp
More information about the xdg