Camel + Empath
- From: Rik Hemsley <rik kde org>
- To: gnome-kde-list gnome org
- Cc: Dan Winship <danw helixcode com>, Bertrand Guiheneuf <bertrand helixcode com>
- Subject: Camel + Empath
- Date: Thu, 16 Mar 2000 03:17:13 +0000
Hi,
I recently noticed 'The Camel Messaging Library', a document on
the helixcode site at http://www.helixcode.com/tech/camel.php3
Reading through, I'm struck by the similarities in design between
Camel and Empath.
Apart from a few differences, such as Camel using streams (Empath
only uses them for easy saving/loading to/from indices) and
(C++) exceptions, the systems are virtually identical.
Empath used to have its message parser built in, but it's now
split into a separate library called 'librmm'.
On incompatibilities between string classes:
I'm not sure what kind of a string representation is used in
GNOME libraries. KDE uses Qt's QString, which is an abstraction
of a 16-bit Unicode string.
librmm uses 'QCString' only - as messages are best treated as
8-bit. Empath itself (the 'kernel') uses QString, but perhaps
this can be made to work with whatever Camel is using ...
I'd like to have some form of co-operation between the two
projects. Empath has been going since October 1998 and is reaching
maturity. If it's impossible to merge the libraries, perhaps
it would be possible to agree on some standards to allow
interoperation.
BTW, 'Empath' is often represented as a standalone GUI mail
client. It's actually a completely separate kernel plus a
message parsing library. None of the code in Empath's kernel
knows about any UI that exists, so there are no nasty dependencies
going on there.
Recently I've converted some of Empath's UI to kparts, which
I believe is the equivalent of Bonobo objects. It seems to me
there's scope for collaboration here.
Comments ?
Rik
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]