[Evolution] mail TODO

[Dan Winship <danw helixcode com>]

As promised a few days ago on the #evolution irc channel, here's a
list of things that need to be done in the mailer.

If you're planning to tackle something (or if you just have questions
about something), send mail to the list.


Problems in Camel
-----------------
* Stores need to be cached, so that asking a session for the same
  store twice will give back the same store both times. Ideally,
  asking for "pop://danw trna" and then
  "pop://danw;auth=* trna helixcode com/" would give the same store as
  well. (But what if incompatible auth types are specified?)

* CamelURL should do %-escaping (maybe just use libxml?)

* CamelFormatter does not belong in Camel.

* The handling of headers by CamelMedium and its subclasses is broken
  in various ways. Doesn't properly do RFC822 or RFC2047 parsing.

* CamelFolder attributes/flags need to be implemented (especially
  "unseen"), both generically and for mbox. See also IMAP spec.

* Camel currently has no concept of memory management. None at all.
  It's just one big memory leak basically.

* lots of things should use glib preconditions but don't. Some places
  use inappropriate ones (treating non-fatal errors as fatal, or
  vice versa). There may be a few places that are still using
  CamelException where they should be using preconditions.

* lots of things should use CamelException but don't.

* lots of things should check errno but don't. In particular, lots of
  reads, writes, and closes go unchecked. (Yes, close can fail,
  especially if you're writing into AFS.)


Camel Providers
---------------
* mbox provider pretty much needs to be re-written

* IMAP provider needs to be written

* vFolder provider

* MH and maildir providers need to be updated or scrapped. They want
  to share summary and indexing/searching code with the mbox provider
  most likely, which may require code reorganization.

* It should be possible for a single provider to be both a store and a
  transport. It should be possible for a provider to handle multiple
  URL types. (The news provider will need to do both of these.)

* Providers need some sort of "domain" so the mail source
  configuration stuff knows to not offer to let users fetch their mail
  from an NNTP server.

* There's no way for a provider which isn't shipped with Camel to
  define its own range of CamelExceptions. (Are we ever actually going
  to use the numbers though? Maybe CamelException can become a
  strictly string-based API.)



Mail component
--------------
* configuration stuff (mail sources, transports, identity, ?)

* configuration system for all folders.

* connect folder browser to composer (reply/forward)

* searching/filtering. (The filtering stuff needs to be completed, and
  the API needs to be finished.)

* trash folder

* mail printing

* attachments should be dealt with better