On 28-feb-04, at 3:06, Bruce Lilly wrote:
Not with IMAP, where the message store typically lives on the
server
Well, then a new client would have to download all the messages from
the
server again, wouldn't it?
No.
Ok, it seems we're not communicating. I assume the client would want to
have a local copy of all messages, you seem to assume that the client
wouldn't want to have local copies of any messages. Regardless, if you
use IMAP then the fact that MUA #1 has downloaded a message doesn't
save MUA #2 from having to download it too if the user wants to look at
it.
There is rarely
any reason to examine every byte of every file using IMAP with
the type of storage described (one file per message).
What you're saying has no bearing on my objection that using a file per
message takes much, much more disk space than aggregating messages into
a smaller number of files.
Yes, *today*. With a system that includes message sizes the body can
be
skipped
IIRC, that's been tried ("Content-Length" stored in the message
header), and it has led to corrupted mailboxes.
This is all physical database design 101, there are people around who
are actually capable of implementing something like this correctly.
It would be pretty stupid to store messages such that an operation is
done once a month can be performed easily while operations that happen
every minute suffer.
What is the basis for your statement that "operations that happen
every minute suffer"?
Having to store binary data in text files as opposed to text in binary
files means that all access to all data, but especially binary data, is
less efficient. I'm assuming people are accessing data on a mail server
every minute.
Anything that displays the text between the tags is a valid HTML
implementation.
You're joking, right?
No joke. Anyone who writes HTML and makes assumptions about what will
be displayed other than the text between the tags in some form or
another lives in a fantasy world. Why do you think so many websites
specify the user agent to be used for visiting them?