mirror of
https://git.code.sf.net/p/archivemail/code
synced 2025-01-02 21:24:40 +00:00
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:
parent
77481169d8
commit
1fcd5b7292
1 changed files with 14 additions and 0 deletions
14
TODO
14
TODO
|
@ -10,6 +10,20 @@ LOCKING & Co:
|
||||||
sane way, see Debian bug #349068. mbox_sync_mailbox() in the mutt code might
|
sane way, see Debian bug #349068. mbox_sync_mailbox() in the mutt code might
|
||||||
be an example how to write back a changed mailbox.
|
be an example how to write back a changed mailbox.
|
||||||
* Double-check the entire locking code.
|
* 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
|
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
|
least be documented. E.g. I've found that '-d 0' didn't match all messages in
|
||||||
|
|
Loading…
Reference in a new issue