EVOLUTION-MANAGER

Edit File: commndmt.txt

/* ======================================================================== * Copyright 1988-2006 University of Washington * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * * ======================================================================== */ [I wrote this tongue-in-cheek, but there's a lot here that people who build IMAP clients should take careful note. Most existing clients violate at least one, generally several, of these commandments. These are based on known user-visible problems that occur with various commonly used clients. Put another way, behind each commandment is a plethora of user (and server administrator) complaints caused by a violator.] Ten Commandments of How to Write an IMAP client Mark Crispin 1. Thou shalt not assume that it is alright to open multiple IMAP sessions selected on the same mailbox simultaneously, lest thou face the righteous wrath of mail stores that doth not permit such access. Instead, thou shalt labor mightily, even unto having to use thy brain to thinketh the matter through, such that thy client use existing sessions that are already open. 2. Thou shalt not abuse the STATUS command by using it to check for new mail on a mailbox that you already have selected in an IMAP session; for that session hath already told thou about new mail without thy having to ask. 3. Thou shalt remember the 30 minute inactivity timeout, and remember to speak to the IMAP server before that timeout expires. If thou useth the IDLE command, thou shalt send DONE from the IDLE before 29 minutes hath passed, and issue a new IDLE. If thou maketh no use of IDLE, then thou shalt send NOOP every few minutes, and the server shalt tell you about new mail, and there will be much rejoicing in the land. 4. Thou shalt not assume that all names are both the name of a mailbox and the name of a upper level of hierarchy that contains mailboxes; lest thou face the righteous wrath of mail stores in which a mailbox is a file and a level of hierarchy is a directory. Thou shalt pay diligent attention to the \NoSelect and \NoInferiors flags, so that your users may praise you with great praise. 5. Thou shalt learn and understand the unique features of IMAP, such as the unsolicited data model, the strict ascending rule of UIDs, how UIDs map to sequence numbers, the ENVELOPE and BODYSTRUCTURE structures; so that thou may use the IMAP protocol effectively. For a POP client hacked to babble IMAP protocol is still no more than a POP client. 6. Thou shalt remember untagged data sent by the server, and when thou needest data thou shalt consult your memory before asking the server. For those who must analyze thy protocol transactions are weak of stomach, and are likely to lose their recent meal should they see thou repeatedly re-fetch static data. 7. Thou shalt labor with great effort to work within the IMAP deleted/expunge model, even if thy own model is that of a trashcan; for interoperability is paramount and a trashcan model can be done entirely in the user interface. 8. Thou shalt not fear to open multiple IMAP sessions to the server; but thou shalt use this technique with wisdom. For verily it is true; if thou doth desire to monitor continuously five mailboxes for new mail, it is better to have five IMAP sessions continuously open on the mailboxes. It is generally not good to do a succession of five SELECT or STATUS commands on a periodic basis; and it is truly wretched to open and close five sessions to do a STATUS or SELECT on a periodic basis. The cost of opening and closing a session is great, especially if that session is SSL/TLS protected; and the cost of a STATUS or SELECT can also be great. By comparison, the cost of an open session doing an IDLE or getting a NOOP every few minutes is small. Great praise shall be given to thy wisdom in doing what is less costly instead of "common sense." 9. Thou shalt not abuse subscriptions, for verily the LIST command is the proper way to discover mailboxes on the server. Thou shalt not subscribe names to the user's subscription list without explicit instructions from the user; nor shalt thou assume that only subscribed names are valid. Rather, thou shalt treat subscribed names as akin to a bookmarks, or perhaps akin to how Windows shows the "My Documents" folder -- a set of names that are separate from the hierarchy, for they are such. 10. Thou shalt use the LIST "*" wildcard only with great care. If thou doth not fully comprehend the danger of "*", thou shalt use only "%" and forget about the existance of "*". Honor these commandments, and keep them holy in thy heart, so that thy users shalt maximize their pleasure, and the server administrators shalt sing thy praises and recommend thy work as a model for others to emulate.