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
>

