Re: Camel + Empath

[Bertrand Guiheneuf <bertrand helixcode com>]

Rik Hemsley wrote:

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

Camel draws heavily from JavaMail, with a few noticeable
differences, though. I don't know exactely about Empath,
but this may be an explanation of the similarities.

>

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

I looked at Empath once, but I thought that it was being replaced
by a project called Magellan.

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

We use Tom Tromey's libunicode.

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

I don't think it would really valuable to merge the two libraries.
Because it is intended to soon have other language bindings,
Camel is intentionnaly written  written in C while Empath is
written in C++. On the other hand, Camel uses the Gtk Object
System, which makes it not so well suited to its use within
a C++ project (considering that you already have a working
library).

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

Yes, I guess that there is here a point of cooperation. I am sure that
the evolution of Bonobo and the KDE component system (I thought
it was not called kparts anymore), will bring more compatibilty in
the future.


>
>
> Comments ?
>
> Rik

This is a very interesting proposition. I regret that it
occurs only now, as I have worked more that one year on Camel.
It is possible that we may have saved some efforts if we had
been aware of each other before.
I guess that it is too late now. Camel is now rock solid software,
and we are currently working on the various providers.
I am sure that Empath is also a very good library.


Regards,

    Bertrand.