Re: [Evolution-hackers] Camel Standalone - any hacker docs?

[Not Zed <notzed ximian com>]

On Mon, 2004-10-11 at 14:51 +0700, gordon wrote:
> <rant>Hiya, thanks for great work...nicely written.</rant>
>
> After mild pain I have a standalone version of Camel building and a 
> fairly banal test program which sends an smtp mail ok.
>
> I hacked out a subset of e-util and some other deps..and am not building 
> gw yet as it needs eds/soap etc ...
Looking forward we're almost certainly going to need to add soap in there somewhere.  Although actual backends like groupwise don't specifically need to be part of the camel build itself, etc.

We can't just move the e-util stuff into camel without changing function names and so on too, which is a bit of a pain, or removing them entirely from e-util instead (which may make sense, definitely more-so if it went into eds which also has some copies of e-util stuff).
> Im looking for any good design rationale/notes/roadmap docs...any urls?
Only the source.  There's some old devel docs and text files around in the source, but they're probably out of date.  There are some discussions in the hackers archives too.
> I need to grok -
> o future roadmap of Camel
We're considering breaking it out for 2.2, but that depends on resources a bit.  If that is done it might still be a couple of releases before it stabilises api-wise enough for external apps, a few things need work (Store and Folder, and i'd like to fix some Mime vs MIME namespace type stuff).

One thing that might happen is to split it into two main parts, a 'mime/message' handling bit (including the datawrapper heirarchy, basic streams, etc), and a backend storage/network handling bit (stores/transports, maybe network streams, etc).  i.e. two separate but related libraries.

There are a bunch of things we need for new features too, like for server-side filtering.
> o future plugin structure for auth and messaging
What do you mean, beyond storage backends?  Because camel is pretty modular its need for various types of plugins is less than the need inside evolution itself.  e.g. a new sasl auth method could just be a compile time option.  Its GPL so there's no real difference including the auth implementation source in the tree vs run-time loadable.
> o what the needed headers are for external use -
>     can we reduce number??
Whatever headers you need normally.  i.e. whatever subsystems you're using.  I see no reason to change this structure.
> o anybody else working on same area [standalone build]?
Not that they've mentioned, so I guess not.
> o imap/imapp/imap4 status + roadmap?
I think imap4 is intended for 2.2, i suspect imap will be maintained until at least then, imapp is more a long-term private thing of mine.  But these are sort of internal issues that don't affect other parts of the library too much.
> My feeling is now is the time to make it seperate, before more 
> dependencies get added - my $0.02 is behind keeping it outside of both 
> evo and eds. 
Well, we wont be adding more unecessary dependencies, since at this point we know we will separate it out eventually, 2.4 if not 2.2.

I'm not sure we settled the eds issue.  It has some advantages.  Not the least of which would be the eventual bonobo-serverisation of desktop mail/message stores as with calendaring/etc.  Its main advantage is just maintenance of fewer modules.  Applications having access to mail and eds together i don't see as a disadvantage.
> I suppose it should also have docs of the quality of gmime... if I have 
> time to make docs, almost surely will not be so nice.

--

Michael Zucchi <notzed ximian com> "born to die, live to work, it's all downhill from here" Novell's Evolution and Free Software Developer