67 lines
2.9 KiB
Plaintext
67 lines
2.9 KiB
Plaintext
MBOX-Line: From mrc+imap at panda.com Sun Jun 5 18:24:50 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc+imap@panda.com>
|
|
Date: Fri Jun 8 12:34:46 2018
|
|
Subject: [Imap-protocol] Where to start?
|
|
In-Reply-To: <4DEC1C93.24755.853F5AE5@David.Harris.pmail.gen.nz>
|
|
References: <4DEBB242.2090200@BusCom.net>,
|
|
<201106051924.p55JOwpG003543@mxout12.cac.washington.edu>,
|
|
<4DEBDFF5.9000301@BusCom.net>
|
|
<4DEC1C93.24755.853F5AE5@David.Harris.pmail.gen.nz>
|
|
Message-ID: <alpine.OSX.2.00.1106051813140.809@hsinghsing.panda.com>
|
|
|
|
On Mon, 6 Jun 2011, David Harris wrote:
|
|
> the part that gave me the most trouble was partial fetches of
|
|
> arbitrary data: many clients will use this as a "chunking" mechanism,
|
|
> but it creates a serious state problem of what you keep between
|
|
> commands on the server side (imagine that you have a 20MB
|
|
> message and the client wants to retrieve a MIME sub-part from the
|
|
> middle of it 1K at a time: if you re-parse and re-extract the sub-part on
|
|
> each chunk, you'll absolutely kill your server's performance - you need
|
|
> to find some way of caching the sub-part so you can easily return
|
|
> subsequent requests for the next chunk).
|
|
|
|
Good point. My server implementations (note the plural) keep offsets in
|
|
the internal representation of the BODYSTRUCTURE for each body part, even
|
|
though these are not reported to the client, for the specific purpose of
|
|
avoiding this problem.
|
|
|
|
> 3: Overall, IMAP part numbering was far and away the hardest thing I
|
|
> had to do with the protocol.
|
|
|
|
Are you prohibited from looking at existing code? There is a really cute
|
|
recursive algorithm in my mtest testbed program that demonstrates the
|
|
proper way to do IMAP part numbering.
|
|
|
|
It's worth spending the time to understand IMAP part numbering. It seems
|
|
ideosyncratic (as David says), but if you think through the issues you'll
|
|
see that it makes a great deal of sense.
|
|
|
|
It's not what you'd come up with at first to descend a MIME structure
|
|
tree. But once you grasp it, you'll realize that it's cleaner and more
|
|
concise than the obvious one.
|
|
|
|
It does take a while though. It took me a while, with several false
|
|
starts, to come up with it.
|
|
|
|
> From quietly reading this list for many years, I suspect the consensus
|
|
> you will get will probably be something along the lines of "all clients are
|
|
> poor choices", although I personally think that's a bit harsh. I'd test
|
|
> against the clients most likely to be used with your server and be ready
|
|
> to accommodate them as required (some accommodation is almost
|
|
> inevitable, unfortunately).
|
|
|
|
The client that is the best test of all is [al]pine. It uses all of IMAP,
|
|
and if you have something wrong in how you do IMAP it will become obvious
|
|
pretty quickly.
|
|
|
|
It would be a very obscure server bug indeed which is not caught by
|
|
[al]pine yet caught by some other client.
|
|
|
|
-- Mark --
|
|
|
|
http://panda.com/mrc
|
|
Democracy is two wolves and a sheep deciding what to eat for lunch.
|
|
Liberty is a well-armed sheep contesting the vote.
|
|
|