On 29 Sep 2004, Michael Wener wrote: : : My goal and intent at the moment is to understand the concept of a : session within IMAP.
The best explanation I've ever heard on this list is to think of the mailstore as a "world" or "environment" and the server is describing the world to the client session. The client accepts the descriptions from the server and can also ask the server to do things. The server describes the results of the client's requests, but it can ALSO describe things that have NOTHING to do with the client's requests. (Untagged responses.) In fact the server is obliged to tell the client these things. These are things that may have been initiated in another session, or initiated by the server itself, doesn't really matter. I wish I could find the original post because it was much more well written. So instead of thinking of IMAP as client request, server response, client request, server response, etc, think: client request, server says "this happened, and that, and this, and by the way that thing you asked for is now done." The "this and that" are the untagged responses, one of which may be relevant to the client's request. Get your brain around the concept that the server can - and must! - tell you ANYTHING, not just the things you asked for, and then it starts to make more sense. The implication of this is that a session should not assume anything except exactly what the server tells it. (In my opinion) debating about shared state is irrelevant. You don't need to share state with other sessions, because when something happens the server is going to describe it to all sessions. Don't take directions from other sessions. To make a tenuous analogy, that would be like your tour guide telling you turn left, but you insist on turning right because some dude on the street corner told you to. -- "Within nine days of its release the very first exploit for IE 3.0 was discovered and released to the public. The rest ... is history." - Josh Ryder
