[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!

>

> Cheers!

>

> -- 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

> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol

>




More information about the Imap-protocol mailing list