TODO: added issues:

- no locking with archives
- no validation of existing archives
- discomfort with current mbox class design and usage
This commit is contained in:
Nikolaus Schulz 2008-01-19 00:12:35 +00:00
parent 77481169d8
commit 1fcd5b7292
1 changed files with 14 additions and 0 deletions

14
TODO
View File

@ -10,6 +10,20 @@ LOCKING & Co:
sane way, see Debian bug #349068. mbox_sync_mailbox() in the mutt code might
be an example how to write back a changed mailbox.
* Double-check the entire locking code.
* FIXME: no locking at all is applied to the archives.
Seems like existing archives are not read or validated in any way. New archive
data is blindly appended... Probably okay, but should be documented.
I don't like the representation of mboxes as python objects, it's unclean.
E.g. the archive mbox object is a subclass of mailbox.UnixMailbox, but this
super class is not used in any way, it's not even initialized. Makes sense,
since we need write-only access, and UnixMailbox is read-only. But should it be
a subclass at all, then?
.
Also, the original mbox and the "retain mbox" are separate objects. This is
disputable. E.g. the finalise() method of the retain mbox overwrites the
existing original mbox, and I feel that's really unclean.
IMAP SEARCH BEFORE disregards time and timezone information. This should at
least be documented. E.g. I've found that '-d 0' didn't match all messages in