Re: [Evolution-hackers] Camel plans and possibilities

[Not Zed <notzed ximian com>]

On Thu, 2003-06-26 at 23:27, Dan Winship wrote:
> >  - do we remove non-threaded case code?
> 
> Has it ever even gotten much testing?

Well bits were when they were written, but i doubt it even builds
anymore (noticed at least a few cases where pthread code isn't
protected).  Fixes up a bunch of issues with feature tests in the
headers too.

> >  - need to consider breaking up directory structure
> 
> libcamel is already very nearly split into two pieces, one that does
> MIME parsing, and one that does providers/services (which depends on the
> first part). You could even make them two separate libraries. (And then
> things like ebook wouldn't need to be pulling in CamelTcpStreamSSL,
> etc.)

Hmm, good point.  That might be an idea, the two libraries.  Libtool
makes it a mess to try and separate the stuff into separate dirs and
make a single library anyway :-/.

Perhaps
 mime stuff library (incl mimemessage? and some basic streams)
 provider stuff (provider, store, etc, remote streams?)
 provider plugins (or as they are now)
 sasl plugins         "
 sign/encrypt plugins "
 
> >  - what to do about e-util - we only use a few non-gui related files
> > from e-util,
> 
> Some of those things (e-msgport, e-memory, e-trie) are used only by
> camel and evolution-mail anyway.

Yeah.  Some of the newer glib stuff makes things less required too
(recursive mutexes), although i dont really like their api mappings, as
a rule.  dlist is useful everywhere but its definitely a me-ism (it
replaces glist, gqueue functionality with a much simpler, efficient, and
more general list implementation).  The ethread stuff should probably be
moved to gthread if it has the right features (tho it would mean more
file descriptor use and some extra overheads).  msgport is handy as a
simple/efficient non-copying asynchronous & thread safe message queue.

> > camel-exception.h
> 
> Should CamelException just be changed to GError? The APIs are pretty
> similar.

I guess its a possibility, but since little else uses GError, probably
less useful than it might be.  i.e. we gain nothing but a big
search/replace task (error prone since the semantics are just different
enough), and then lose any future flexibility we might have (e.g.
subclassable/extensible exceptions).

> > camel-medium.h
> 
> Is this ever going to have a subclass besides camel-mime-part? (I guess
> if we were going to have a CamelNNTPMessage it might go there, but it
> would have to duplicate a lot of CamelMimeMessage, and the display code
> in mail/ only handles CamelMimeMessages anyway...)
> 
> If not, it seems like it would make sense to just merge this up into
> camel-mime-part.

Yeah maybe.  In the JavaMail API a lot of these things are only
interfaces.  But they also have more layers, e.g. part and message of
which mimepart and mimemessage were implementations.

NNTPmessage is probably close enough we can fudge it (if anyone ever
cares enough about nntp), but things like fax or voice mail is another
matter (even then, they could possibly hide behind a mime interface).

> > camel-multipart.h
> >  - should be purely abstract, with a camel-mime-multipart subpart?
> 
> Same comment as with camel-medium.

Although in this case we do have several subclasses, multipart-signed
and multipart-encrypted, both of which override (i think) the main
functionality in multipart.

Wonder if the get_part() stuff could be iterative, and potentially allow
a backend to parse a message incrementally.  Maybe not, it gets too
tricky.

> > camel-transport.h
> 
> sendmail, smtp, and exchange all use the same non-thread-safe hack to
> make sure the bcc header doesn't end up in the outgoing message. It
> would be nice to clean that up somehow. (CamelMIMEFilterStripBcc?)

Problem is it'd have to parse enough of the headers to grok it.  Maybe
not that hard since it only has to do the top-level parse/header fold,
and then be a cost-free noop after the first headers are finished.  A
general purpose one that stripped any header would probably be the way
to go.

But also, maybe a new mime_part/medium::write_to_stream(part, flags)
call, or similar where you could tell it to force 7/8 bit, hide
X-Evolution* (X-Camel?), or BCC headers etc.  SMTP does some message
re-configuring during output too which is a bit of a nono.

> > camel-folder.h
> >  - should this be able to be created, unopened?
> 
> Yeah, and ideally you would be allowed to append messages to or move
> messages to an unopened folder (so you don't have to suck down the
> contents of your IMAP Sent folder just so you can append another message
> to it). (In the local folder case, it would have to implicitly open the
> folder when you did this I guess.)

It would only need to when you append, and open the summary/index as
well.  Not trivial but doable.

> > camel-folder-summary.h
> >  - maybe it should just be an interface
> 
> Well, there's a lot of useful code in there that all of the providers
> use. (message_info_load/save, etc). That wants to be somewhere where
> they can all share it.

I'm trying to remember what i was on about ...

I think, an interface on the folder.  e.g. you access the methods
directly 'via the folder'.

If camelinterfaces were not entirely abstract, but more like lightweight
(or full?) classes that can be attached to another class, not much would
change at the implementation side.  (i'm still not sure about the
camelinterface idea - but its a possibility if it can be done simply).

One problem with the class anyway is that the api doesn't really fit
anything other than local mail folders (and even then, only really
maildir that well).  IMAP needs workarounds, since most of its workings
are index based, not append and forget based.  At worst, it can stay as
it is, since its really only for store-internal use anyway.

> > camel-disco-store.h
> > camel-disco-folder.h
> > camel-disco-diary.h
> >  - please die and go to hell :)
> 
> Yeah, no argument there.

If only replacing the functionality was that easy ...

> > camel-mime-filter-tohtml.h
> 
> Is this used for anything but generating MessageDisplay? It still
> doesn't get all of the autodetecting cases right that e_text_to_html
> does. (The one I noticed most recently is the opening quote in
> 'foo bar com'.)

Well, problems can be fixed.

I still think its a reasonable way to go ... although i'm not entirely
sure it belongs in camel itself (same with text/enriched etc), it could
just as easily live in the mailer.  Camel needs the de-html filter for
indexing though - although i really want to find a way to remove
indexing to a plugin anyway.

Mainly though, camelstream is more feature rich than gtkhtmlstream, and
basically, the whole mail-format code (and the refactor i'm working on)
base all output and processing on camel streams.  It simplifies the code
design quite a lot by having a common stream architecture throughout
(fortunately the mapping stream to gtkhtml stream is trivial, and as a
bonus adds refcounting for us).  Having raw message data, if that route
is chosen, will only emphasize this more (e.g. having to do a qp decode,
then charset conversion, then html conversion on a blob of data headed
to the screen).

> > camel-movemail.h
> >  - probably needs to make runtime decision about solaris style mailbox
> 
> (Does Solaris even still use Solaris-style mailboxes?)

Good question.  Still get the odd whine about messages being split in
the middle though, so .. maybe .. or some old mail system is still in
use.