Re: Camel + Empath

[Rik Hemsley <rik kde org>]

#if Bertrand Guiheneuf
> > 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.

Ah ok, I haven't seen 'JavaMail'. Empath was dreamed up over many
nights lying in the bath drawing pictures ;)

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

Well Magellan looks like being a nice client. Its aims are somewhat
different to that of Empath though. I'm trying to provide a solid
mail-processing kernel and rfc822-handling library for use within
KDE and KDE apps, plus some reusable widgets, made available via
kparts, that can be embedded in any KDE app, so the default KDE
mail and news clients can have a common look+feel and share code.

Magellan looks like it's headed towards being a 'do everything
in one place' type of project, a bit like MS Outlook (not that
I've used Outlook, but that's what it says on the Magellan
project page).

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

Oh... from the web page on helixcode.com I got the impression it
was C++, as you have some code that looks like 'ClassName::'.
Oh well ;)

I can see that it wouldn't be worthwhile trying to combine the
projects' code in this case. I'm certainly open to sharing any
ideas + code + design that we can though, so shout if you want
to chat.

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

I don't know how technically possible it is for Bonobo and KParts to
work together. Embedding a kpart in a Bonobo shell or vice versa
sounds like hard work to me ;) But while I understand KParts, I have
no clue about what Bonobo does aside from part embedding, so I'll
have a closer look.

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

Ah.. I just heard of Camel yesterday. Where have you been hiding :)
Oh well, at least I feel better about my design (I hadn't written
any major code before I started on Empath, so it has been a learning
process) after seeing that Camel is so similar.

Well I wish you luck, thanks for the reply.

Rik