On Tue November 2 2004 10:52, Keith Moore wrote:
http://cr.yp.to/proto/maildir.html is as close to a specification
as I know of.
[...]
the reason I've been thinking of maildirs is that it's simple to use,
it's robust, there are already IMAP and POP protocol servers that
support it, and it's not too difficult to make maildirs accessible by
WebDav and FTP either. they are a tad awkward for WebDav and FTP access
(as there are reasons you want to support a hierarchy of folders
and maildirs use an extra layer of directories) but I don't think this
is onerous.
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.
there are lots of tools that edit mbox files, e.g. ucbmail.
With corresponding locking issues, etc.
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.
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.
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.