I'm assuming that archives are read-only, so archives stored in
maildirs shouldn't result in files being renamed.
According to
http://www.washington.edu/imap/documentation/formats.txt.html
and confirmed by the URI that you provided, file names change
whenever status (e.g. seen) changes, and that would seem to
apply even in an environment where folders are read-only from
an IMAP protocol perspective.
IIRC, SEEN should not change in a shared folder.
there are lots of tools that edit mbox files, e.g. ucbmail.
With corresponding locking issues, etc.
yup. but assuming archives aren't changed very often, these
seem managable.
being able to store lots of messages in a single file can save a
lot of disk space, particularly if you compress those mbox files.
I suppose that's so in general. However for the problem
domain (a server), disk space with modern hardware
isn't generally an issue. If it is deemed to be a greater
issue than compression/decompression overhead for a
particular instance, compression can be implemented in
the file system, independent of storage format.
that's much more difficult to do. the point is to make this easy.
in my experience most IMAP clients don't do a good job with folders
that large. I'm thinking that archives should be able to support
hierarchal directory trees.
Some clients do seem quite a bit slower than others (that
applies to other protocols, e.g. POP3, as well). It depends
on what a particular client requests, and for a listing of
an entire folder (as opposed to a fetch of a particular
message), the number of messages in a folder could be
an issue with some clients, on the first access of that folder
by that client, for some client implementations.
yup. some client implementations want to download every message
in the folder; others want to download headers from every
message in the folder. these behaviors are quite common.
I think one of the biggest practical issues with Archived-At
support is arranging for the URI(s) to be put into the
message before the message is placed in the archive; the
URI (related to archive file name and/or UID) might not
be determinate until the message is actually placed in the
archive.
that's fairly easy to solve. send the messages to the archiver
before distributing them to list subscribers.
+----------+ +----------+ +----------+
incoming | incoming | | | | list |
message ----> | mail | ----> | archiver | ----> | expander |
| filter | | | | |
+----------+ +----------+ +----------+
| | |
V V V
rejects archived subscribers
messages
either that or base the name of the archive on some property of
the message that can be derived independently, say the message-id
or a hash of some kind.
Keith