61 lines
5.8 KiB
Plaintext
61 lines
5.8 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Tue Mar 10 21:41:17 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
|
|
it be different?
|
|
In-Reply-To: <86FE3C0E-8F89-4721-B43F-C3126C7C211F@orthanc.ca>
|
|
References: <54FAEB94.4070508@lavabitllc.com>
|
|
<86FE3C0E-8F89-4721-B43F-C3126C7C211F@orthanc.ca>
|
|
Message-ID: <1426048877.2620861.238715525.20928B48@webmail.messagingengine.com>
|
|
|
|
On Wed, Mar 11, 2015, at 01:23 PM, Lyndon Nerenberg wrote:
|
|
>
|
|
> On Mar 7, 2015, at 4:14 AM, Ladar Levison <ladar@lavabitllc.com> wrote:
|
|
>
|
|
> > I thought this might be a good list to ask a simple, but admittedly
|
|
> > subjective question: If Mark Crispin was creating IMAP from scratch, in
|
|
> > the world of today, would it still be a line based protocol like it was
|
|
> > with RFC3501, or would he have gone with something more stateless, like
|
|
> > a JSON-RPC paradigm, like JMAP?
|
|
>
|
|
> [ Coming in a bit late, I realize ... ]
|
|
>
|
|
> For MRC, state was king. And for a remote mailbox access service, he believed state was critical to building an efficient protocol.
|
|
>
|
|
> He would have scoffed at comments about 'line' vs 'streaming' and 'text' vs 'binary' as indicative of the spewer of such nonsense being beneath contempt ;-) What Mark got, and what so many other self-proclaimed experts in this discussion are blissfully oblivious to, is that it's the RTTs that kill an interactive protocol, and nothing else. He firmly believed that every IMAP client developer should be forced to work behind a 1200 bps (yes, 1200) network link. He rightly surmised that that was the only way to ensure an IMAP client would make the most efficient use of the protocol. And I agree completely, although I did try to convince him that 9600 bps was perhaps a reasonable compromise.
|
|
|
|
This has been really good for us designing JMAP, because we are in Australia and our servers in New York, so latency is a real consideration for us. Round trips are a big deal.
|
|
|
|
> Many times we talked about what the son-of-IMAP might look like. For quite a few years I have been bouncing around an idea for an MUA access protocol. Conceptually it is very different from IMAP, but it retains the philosophy in many ways. I had some wonderful nights having my skin blistered by his critiques. Fortunately there was a lot of beer at hand to quench the flames :-) The once thing we did - almost - come to agreement on was that a purely Sexpr-based protocol syntax was the right way to do it. He always got grumpy talking about what he considered the deficiencies and compromises in the IMAP syntax that were 'forced' on him by others. (How much of that was actually true I can't speak to. But I know there are people still likely reading this mailing list who mightily pissed him off over what he perceived to be political manipulation of the spec for corporate gain.) (I also can't believe that he didn't just tell them to "see figure one," but there you go.)
|
|
|
|
Have you had a look at jmap.io? I would have loved to see Mark's feedback on it. I suspect sitting down and talking over beers would have been more valuable than talking over email, because describing things over email is hard.
|
|
|
|
JMAP is very much inspired by IMAP and built on the raw concepts. The one place where Mark and I disagreed a lot was on the one canonical ordering (last arrived) for the mailbox, and all the state being easy to use if you wanted that ordering, but impossible or very hard for everything else. Trying to get an efficient view on something OTHER than last arrived on a million message mailbox is crazy with IMAP.
|
|
|
|
Which means copying in old messages from an archive mixes things up. Most clients seem to want to sort to either INTERNALDATE (received date) or the Date: header.
|
|
|
|
So in JMAP we actually make the server keep more state so that we can provide efficient updates to whichever that the client wants, including sorts or searches (which allows things like a view of unread messages, or pinned messages on top as a mailbox view)
|
|
|
|
> What I took away from our conversations was this. He thought the explosion of IMAP extensions pointed to a fundamental flaw in the design of the protocol, one that needed fixing. He could not pin down, to his own satisfaction, what that flaw was (or flaws were); he had his own misgivings about some of the design, but he was never forthcoming to me about what he thought they were. (He didn't want to criticize anything until he knew he could shred it with 100% validity, and that included his own work.) But he also thought at least some of the extensions were due to pure laziness and ineptitude on the part of client writers. (He could peel paint with that topic of conversation!)
|
|
|
|
I'd say there's half and half here. The fact that you could only do windowing by message number, and everything else was full mailbox search/sort was a big issue for clients. And getting updates to everything you're interested in.
|
|
|
|
> I miss the cranky bastard, with his guns and politics and libertarian take on life :-) We were polar opposites on the first two of those three (maybe all of them), but he respected what you had to say, even as he let loose with how he thought you were a complete idiot and did not deserve to grace a keyboard with your fingers :-)
|
|
|
|
Yep, I remember those!
|
|
|
|
> As April approaches, I hope you will all join me in raising a glass of something uncomfortable in his memory, while you read one of his great works: http://www.ietf.org/rfc/rfc748.txt
|
|
>
|
|
> Especially the young turks recently gracing us with their presence. They might learn much. Or not.
|
|
|
|
I think a glass of something uncomfortable will work well with reading that one! I'll be on a boat between Melbourne and Tasmania on that night, and I'll definitely drink a glass of something horrible in his memory.
|
|
|
|
Bron.
|
|
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|