Re: [Evolution-hackers] Camel plans and possibilities
- From: Dan Winship <danw ximian com>
- To: Not Zed <notzed ximian com>
- Cc: evolution-hackers ximian com
- Subject: Re: [Evolution-hackers] Camel plans and possibilities
- Date: 26 Jun 2003 09:57:12 -0400
> - do we remove non-threaded case code?
Has it ever even gotten much testing?
> - 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.)
> - 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.
> camel-exception.h
Should CamelException just be changed to GError? The APIs are pretty
similar.
> 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.
> camel-multipart.h
> - should be purely abstract, with a camel-mime-multipart subpart?
Same comment as with camel-medium.
> 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?)
> 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.)
> 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.
> camel-disco-store.h
> camel-disco-folder.h
> camel-disco-diary.h
> - please die and go to hell :)
Yeah, no argument there.
> 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'.)
> camel-movemail.h
> - probably needs to make runtime decision about solaris style mailbox
(Does Solaris even still use Solaris-style mailboxes?)
-- Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]