109 lines
4.8 KiB
Plaintext
109 lines
4.8 KiB
Plaintext
MBOX-Line: From Lynn at BusCom.net Sun Jun 5 21:51:16 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: "Lynn W. Taylor" <Lynn@BusCom.net>
|
|
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: <4DEC5CC4.5010507@BusCom.net>
|
|
|
|
I think you read me saying "this isn't my first time at the rodeo" and
|
|
think that I actually enjoyed the rodeo.
|
|
|
|
I expect it to be slow, and grueling, and difficult, and worth doing.
|
|
|
|
I firmly believe the rule that states "everything takes longer than you
|
|
expect, especially when you take this rule into account."
|
|
|
|
... and I very much appreciate things like your comment about spaces.
|
|
That kind of shared pain is worth its' weight in gold.
|
|
|
|
On 6/5/2011 5:17 PM, David Harris wrote:
|
|
> On 5 Jun 2011 at 12:58, Lynn W. Taylor wrote:
|
|
>
|
|
>> Search (#10) is the one that worries the most. Some of that is the same
|
|
>> reason that COPY doesn't bother me. Glad it can be left to last, and
|
|
>> wish it could be left out.
|
|
> Lynn, first off, good luck with this. I admire your confidence and
|
|
> enthusiasm, but I suspect you will find the job quite a bit bigger than
|
|
> you expect.
|
|
>
|
|
> To me, IMAP seems as much a matter of mindset as it is of code - you
|
|
> *must* think in much the same the way the people who have written
|
|
> the IMAP RFCs over the years have thought, or you will inevitably fall
|
|
> afoul of details that might not at first glance be obvious - a good
|
|
> example, for instance, is that spaces are syntactically crucial
|
|
> throughout much of the IMAP command structure (especially in
|
|
> BODYSTRUCTURE): for many programmers accustomed to other
|
|
> environments, spaces are not much more than decoration, but you
|
|
> can't think this way in IMAP.
|
|
>
|
|
> The absolute golden rule of IMAP is "read the BNF". It can be tortuous,
|
|
> but in over a decade of working with IMAP (and I do not consider
|
|
> myself in any way an expert or a model for others), I have never found
|
|
> a case where spending the time working my way through the BNF
|
|
> maze did not answer a syntactic question, however thorny it might
|
|
> have seemed.
|
|
>
|
|
> Pete's list was a very, very good one - I found myself nodding in
|
|
> memory and agreement as I read through it. I won't labour the point by
|
|
> repeating things he has said, but I would make three observations:
|
|
>
|
|
> 1: He's absolutely right about the parser. If you don't have a robust,
|
|
> high-quality RFC2822 and RFC2045 (MIME) parser, you're shot before
|
|
> you start.
|
|
>
|
|
> 2: FETCH is full of traps, even if they don't appear to be traps at first
|
|
> glance: 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).
|
|
>
|
|
> 3: Overall, IMAP part numbering was far and away the hardest thing I
|
|
> had to do with the protocol. In my case, I had well-established parsing
|
|
> and message management and I had to shoe-horn IMAP's slightly
|
|
> idiosyncratic part numbering (I'm sure I'll get a lecture for that
|
|
> statement, but I'm allowed my opinions) into it. Because the part
|
|
> numbering is implied, not explicit, it's absolutely crucial that you
|
|
> understand how it works, and how your parsing engine is going to
|
|
> cope with it.
|
|
>
|
|
>> I'm not in a position to specify clients. I'll likely do my initial
|
|
>> testing with Thunderbird unless someone warns me that it's a poor choice.
|
|
> > 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).
|
|
>
|
|
> Good luck!
|
|
>
|
|
> Cheers!
|
|
>
|
|
> -- David --
|
|
>
|
|
> ------------------ David Harris -+- Pegasus Mail ----------------------
|
|
> Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
|
|
> Phone: +64 3 453-6880 | Fax: +64 3 453-6612
|
|
>
|
|
> Seen on the menu of a Swiss Restaurant:
|
|
> "Our wines leave you nothing to hope for."
|
|
>
|
|
>
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
|