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 > '[EMAIL PROTECTED]'.) 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. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
