5 ms·

If nothing else, this seems like a mean time to be disparaging about someone over such little things. :( Look, I'm sad that this guy is dying because that suck

If nothing else, this seems like a mean time to be disparaging about someone over such little things. :( Look, I'm sad that this guy is dying because that sucks. If you want to have a thread commiserating with Crispin and his family and friends over how awful it is to die at 56, that's fine. It is awful. But if you want to have a thread lamenting how awesome a protocol designer we're losing, then you need to accept the fact that some people think Crispin is a bad protocol designer. I haven't spent a lot of time working with IMAP implementations but I have friends who have and they describe pretty serious problems. Perhaps not all of those problems are obvious if you've only implemented a protocol parser and haven't built a working product that's successfully interoperated with popular clients and servers.

saurik 14y ago
(My implementation, which includes my own implementation of Sieve and has a fully-transactional mail storage backend with full-text indexing, keyword flags, and attachment analysis, works fine with all of the clients I have tried it with, including Outlook, alpine, Mail.app, MobileMail, and Thunderbird... look, if you have specific issues to address or evidence from some mailing lists you should bring them up, but now you are just being needlessly insulting entirely based on "my friend said something".)
- MichaelSalib 14y ago
  Well, you could look at the comments at the start of sup's client implementation at http://www.gitorious.org/~einars/sup/utf-sandbox/blobs/95e1f7e3fb05db7f313c49e82040eb6b626fb10d/lib/sup/imap.rb http://www.gitorious.org/~einars/sup/utf-sandbox/blobs/95e1f... to start with. You could also look at http://www.courier-mta.org/fud/ http://www.courier-mta.org/fud/ as geofft mentioned earlier. I'm wracking my brains trying to think of a good reason why a protocol would allow the server to send arbitrary command responses to the client at any time. Or why you'd introduce UIDs but then make them revocable...what possible reason could there be for that? Also, I can understand building a mail protocol that uses UIDs. I can understand building a mail protocol that uses message sequence numbers. I cannot understand building a protocol that uses both and in fact requires both because some protocol operations use UIDs and some use MSNs. Actually, I lied. I cannot fathom why anyone would make a protocol that uses MSNs (they change whenever any client deletes anything! whee!) unless they were mentally trapped in a world where the only message stores were MBOX.
  - saurik 14y ago
    That Courier FUD article does not list a single specific complaint with the specification (well, other than the version number ;P): it just goes over a bunch of personal arguments back/forth and then concludes that it is the fault of the specification that interoperability was poor because interoperability seems poor. As for the UID issue, there are some backends that simply cannot support maintaining a UID as that was not a concept that existed in legacy mail stores. However, it is only an implementation "of inferior quality" that does not maintain them: it's in the category of "SHOULD". """UIDNOTSTICKY is an admission by the server that either the server or the mail store is of inferior quality that can not comply with the design requirements of IMAP UIDs. Not announcing UIDNOTSTICKY, but changing the UIDVALIDITY on a mailbox is an admission by the server that either it or the mail store has an defect that caused it to fail to comply with the design requirements of IMAP UIDs.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/2007-March/000436.html http://mailman2.u.washington.edu/pipermail/imap-protocol/200... The protocol thereby provides a means by which you can tell if you have an inferior server; but yes: it technically allows a server to be inferior because at the time the protocol was released there were no existing mail storage systems that did not have this inferiority. If you still insist on using an inferior server, the result will be weird and will be, well, inferior ;P, but at least it will work. And yes: I've seen that specific block of source code before, because people paste it around all the time as it is fun to complain about things with foul language and insult the things that people do; that doesn't make it an accurate description of the state of affairs, nor certainly does it indicate anything about the design constraints of the protocol. As for why the server is allowed to send arbitrary command responses at any time, most people consider that a feature for the same reason they considered IDLE a feature: the original IMAP protocol was highly asynchronous, and simply streamed protocol state to the client whenever things were updated so that the local client would have a live-updated display. The result is that the protocol, to a very real extent, doesn't even have "command responses": they are kind of a specification concept; instead, it simply has state update messages, and some commands are guaranteed to flush caches and force state updates (which then have timing constraints in when they can be sent, which as a client are mostly irrelevant and for a server are trivially implemented if you do so conservatively).
    - 14y ago

saurik 14y ago

(My implementation, which includes my own implementation of Sieve and has a fully-transactional mail storage backend with full-text indexing, keyword flags, and attachment analysis, works fine with all of the clients I have tried it with, including Outlook, alpine, Mail.app, MobileMail, and Thunderbird... look, if you have specific issues to address or evidence from some mailing lists you should bring them up, but now you are just being needlessly insulting entirely based on "my friend said something".)

MichaelSalib 14y ago
Well, you could look at the comments at the start of sup's client implementation at http://www.gitorious.org/~einars/sup/utf-sandbox/blobs/95e1f7e3fb05db7f313c49e82040eb6b626fb10d/lib/sup/imap.rb http://www.gitorious.org/~einars/sup/utf-sandbox/blobs/95e1f... to start with. You could also look at http://www.courier-mta.org/fud/ http://www.courier-mta.org/fud/ as geofft mentioned earlier. I'm wracking my brains trying to think of a good reason why a protocol would allow the server to send arbitrary command responses to the client at any time. Or why you'd introduce UIDs but then make them revocable...what possible reason could there be for that? Also, I can understand building a mail protocol that uses UIDs. I can understand building a mail protocol that uses message sequence numbers. I cannot understand building a protocol that uses both and in fact requires both because some protocol operations use UIDs and some use MSNs. Actually, I lied. I cannot fathom why anyone would make a protocol that uses MSNs (they change whenever any client deletes anything! whee!) unless they were mentally trapped in a world where the only message stores were MBOX.
- saurik 14y ago
  That Courier FUD article does not list a single specific complaint with the specification (well, other than the version number ;P): it just goes over a bunch of personal arguments back/forth and then concludes that it is the fault of the specification that interoperability was poor because interoperability seems poor. As for the UID issue, there are some backends that simply cannot support maintaining a UID as that was not a concept that existed in legacy mail stores. However, it is only an implementation "of inferior quality" that does not maintain them: it's in the category of "SHOULD". """UIDNOTSTICKY is an admission by the server that either the server or the mail store is of inferior quality that can not comply with the design requirements of IMAP UIDs. Not announcing UIDNOTSTICKY, but changing the UIDVALIDITY on a mailbox is an admission by the server that either it or the mail store has an defect that caused it to fail to comply with the design requirements of IMAP UIDs.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/2007-March/000436.html http://mailman2.u.washington.edu/pipermail/imap-protocol/200... The protocol thereby provides a means by which you can tell if you have an inferior server; but yes: it technically allows a server to be inferior because at the time the protocol was released there were no existing mail storage systems that did not have this inferiority. If you still insist on using an inferior server, the result will be weird and will be, well, inferior ;P, but at least it will work. And yes: I've seen that specific block of source code before, because people paste it around all the time as it is fun to complain about things with foul language and insult the things that people do; that doesn't make it an accurate description of the state of affairs, nor certainly does it indicate anything about the design constraints of the protocol. As for why the server is allowed to send arbitrary command responses at any time, most people consider that a feature for the same reason they considered IDLE a feature: the original IMAP protocol was highly asynchronous, and simply streamed protocol state to the client whenever things were updated so that the local client would have a live-updated display. The result is that the protocol, to a very real extent, doesn't even have "command responses": they are kind of a specification concept; instead, it simply has state update messages, and some commands are guaranteed to flush caches and force state updates (which then have timing constraints in when they can be sent, which as a client are mostly irrelevant and for a server are trivially implemented if you do so conservatively).
  - 14y ago