On Mon, Feb 13, 2012 at 10:55:26AM -0800, Mark Crispin wrote: > I will say this once. Then I will go back to rolling on the floor laughing > at the extremely naive things that certain individuals post here.
Go for it. I said the comments of haters who want to hate were welcome too, and I stand by it. > On Mon Feb 13 2012 07:20:45 GMT-0800 (PST), Cyrus Daboo wrote: > >What is more anyone implementing more than one > >protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only > >have to implement that once, albeit with some minor differences in > >regard to how to get protocol specific pieces for registering for > >notifications. > > This should be self-evident, as is this statement: > > >Frankly, anyone who has a reasonably solid IMAP4 implementation today > >is going to question the need to work on something new, particularly > >if that something new brings nothing to the table (and simply fixing > >interop problems will probably not be seen as something "new"). > > The IMAP5 talk is stunning and laughable in two ways. One is it that it > seeks to make IMAP "simpler". The other is that it seeks to expand its > scope to be Exchange. Simpler as in more regular data model, removing the unnecessary complexity, not the inherent complexity. I believe there is a reasonable pool of unnecessary complexity involved in both ends of IMAP which isn't inherent in the task of viewing and managing email, but is instead caused by the layers of protocol on top - both the irregular syntax of the different layers, and the MSGNO model with its artifacts like 'UNSEEN' which don't match the way in which email is being presented and managed by existing clients today. And then there's the need to support even more parsers and protocol agents for SIEVE, ACAP, and good old SMTP/Submission, plus the support headaches involved in firewall issues. For the 99% case of a client wanting to send an email via the same infrastructure where it stores its email, a basic submission will be sufficient. All of which I've said plenty of times before. I've even added xmove and xsend to Cyrus now. XMOVE is already in use for our own web interface code, removing all the quota issues we used to have with the "Delete to Trash" model, and the crazy workarounds like deleting a small number of messages at a time. There's a draft in progress, and I made sure our implementation is compatible with all the MUSTs. > Unstated, but evident, is a third aspect: the naive notion that a protocol > can be replaced without repeating the work that went into the original. > History shows that the effort in any replacement is quite a bit greater. I'm expecting to do a lot of work. I'm not afraid of work. I'm afraid of getting so bogged down saying it can't be done that we waste another 10 years. > You can't escape that work no matter smart you think you are, or how much > better your knowledge and tools are. You can escape the worst parts of the work by using what already exists, and by not re-inventing every wheel along the way, but by looking at some of the wheels that are a lot smoother than they were 20 years ago. I would prefer to have you involved than sitting on the sidelines laughing, but I'd prefer to do something than listen to you saying it can't be done. Maybe I'll burn out along the way, maybe not. I'm still going to try. Bron. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
