[Imap-protocol] Where to start?
Lynn W. Taylor
Lynn at BusCom.net
Sun Jun 5 21:51:16 PDT 2011
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!
> -- David --
> ------------------ David Harris -+- Pegasus Mail ----------------------
> Box 5451, Dunedin, New Zealand | e-mail: David.Harris at 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 at u.washington.edu
More information about the Imap-protocol