Fine's Home
But this article isn't about how great IMAP is. This article is about why IMAP sucks. So how can something so great suck so much? Well, the idea is great, but the implementation is riddled with inconsistencies that are useless annoyances on the developer tasked with writing an IMAP client.
For some bizarre reason, they decided that lists with one item are a special case deserving special attention. If a body has only one part, instead of presenting it as a list of body parts with only one item e.g. ((TEXT PLAIN ...)), they make it special, making it explicitly one item (TEXT PLAIN ...). On some human level, this almost feels sensible, since it streamlines the look for a human reader. It's just one of many choices where the protocol designers chose to do something that seems "intuitive".
But computers are not humans. All they've accomplished here is to insure that the program has to special case this situation, instead of handling it just like any other list. Just another block of code that is absolutely unnecessary and useless.
But they weren't even consistent about that. If you have a multipart that only has one part, then in that case you do get a list with only one element. Granted, you shouldn't normally have a multipart with only one part, but since it can happen out there in the real world, my code has to handle it.
MIME documents can contain other kinds of MIME documents, hence there's an idea of sub-lists and containers. But again, instead of going simple, they went hard. There are two different kinds of containers - a multipart container, and a message container. They fall into completely different places in the BODYSTRUCTURE format, and have to be handled completely differently, even though they serve the same purpose. More code to handle things that could have been handled together.
And the top level container in the format is always a message/rfc822 structure. But instead of explicitly stating that, the top level is a special case where you simply know in advance that it's a message/rfc822 because what else could it be. Once again, they made the structure seem more human-intuitive, but at the same time, harder for a computer to parse.
The whole point of parsing the body structure is to figure out what sections it has, so the email client can then request those sections. Because of the nightmare described above, there is no simple relationship between the BODYSTRUCTURE results, and the section paths needed to retrieve sections. It should have been the case that the list structure of this result exactly corresponded to the path structure of the section numbers, but they do not.
I do have to slightly concede that point that message/rfc822 containers are special - they always only contain one single element. But I think the failure throughout all of this is to simply accept that and move on. IMAP attempts to "skip over" the rfc822 container layer so that you don't always have the extra path element that aesthetically servers no purpose. In other words, every message will have section 1, the message, and then sub parts to section one if it's multipart. IMAP seems to find never having a top-level section 2 distasteful, but I say so what. Why make my code more complicated to serve some arbitrary designer aesthetic?
Even if you decided this was desirable, it's only a partial explanation. A single exception for skipping over the message/rfc822 layer of the true sdtructure would be acceptable, and everything else could still have been much more regularly formatted.
Somewhat related, but not exactly the same is the subject of section numbers and paths. Why didn't the designer allow the separator to be used as a leading path element. ".1" should mean the same as "1" (the first section). That way when assembling paths using a recursive routing that goes through sublists, I wouldn't need a special case to check and see if the recursion is at the top level.
Why, oh WHY didn't they just stick with string length, and lists, and dump everything else? Yes maybe it's not a bad idea to have IMAP protocol be somewhat human-readable. But the server and client have to go through massive contortions on every object figuring out how to format or parse it. If every object was string-length encoded, the server and client would have a very simple job.
But even within it's own convoluted rules for having useless extra ways of quoting things, IMAP can't resist the temptation to be yet more inconsistent. Server responses like OK and BAD are followed by a text string that can contain any special characters except newline and carriage-return, and do not need to be quoted. The string is terminated by EOL. Great. Up until this bit of bad news, you could at least parse out the IMAP objects without regard to content, even though it was needlessly complicated. Now you actually have to look at the content while you're parsing out the objects, and provide special handling for these responses. Still more useless extra code.
|
Fine's Home
|
|
|
Send Me Email |