On Thu, 30 Oct 2003, DINH [iso-8859-15] Vi$Bj(Bt Ho$B`(B wrote: > could you be more explicit about the problem with delete-expunge model and > unsolicited data model ?
Many clients wish to present a "trashcan" type graphical model, and expect the server to implement that model by means of a "Trash" or "Deleted Items" mailbox. That is, instead of treating the "trashcan" as a client based graphical concept that maps to deleted messages, these clients want the server to do the "move to trash"/"restore from trash" operations as operations between the selected mailbox and the trash mailbox. Many clients are unprepared to receive any data that they did not explicitly ask for via a FETCH, and make no attempt to cache any data. When the server provided unsolicited data, these clients ignore it. This frequently leads to the comical situation in which a client fetches a static datum that the server just gave it, often repeatedly. Both of these are longstanding issues, from almost the inception of IMAP. I still believe that the delete-expunge and unsolicited data models are superior, but if I was starting over today I would probably not design a protocol that uses either. [Knowing my luck, just about the time that new protocol came out, the world will decided that delete-expunge and unsolicited data are the way to go, and some youngster will berate me for being a stupid person who doesn't understand this...much like I hear now from kids who think that threading and mutexes are new ideas that need to be taught to clueless old farts like me... :-( ] I've also noted a recent message talking about how IMAP is too "server oriented." Such comments, and claims that I only think about servers and never about clients, bewilder me. I have been both a client and a server author from the start of IMAP. The first IMAP client and server were designed in tandem, and the division of responsibility was based upon a complete view of both. Nevertheless, when you compare IMAP to other protocols, you observe that an IMAP server is much more of an active partner of the client; and that in most other protocols the server is completely passive. It appears that many client developers perceive IMAP server behavior as an impingement on their choices, and thus prefer server-passive protocols. This is a good lesson to keep in mind. > The problem is that the client has in all case to implement MIME parser > (when they want to do POP3, mbox or such other things), flags are some > other things around and maybe that's why implementors of client don't > bother about implementing these IMAP parts of the protocol. IMAP-only clients *are* possible, but I'll conceed that this is not the way that the world has gone. Nonetheless, clients should not treat IMAP as a glorified POP. ENVELOPE was a reaction to the state of email in the mid 1980s, in which header syntax was regularly violated and no two programs parsed a header in the same way. The idea was that, by using IMAP, all user interfaces would understand the message header in the same way. In many ways, the benefits of ENVELOPE have been overtaken by events; the state of RFC 2822 parsers (and generators!!!) is much better, and many programs need data from headers that is not in the ENVELOPE. But I think that there is still some use for ENVELOPE. BODYSTRUCTURE is another matter. Clients which don't use BODYSTRUCTURE and BODY[...] waste bandwidth, particularly with large MIMEgrams. The same comment applies to SEARCH; an unbelievable percentage of clients download all the messages to the client then do the search locally instead of using IMAP's SEARCH command. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
