[MlMt] JMAP support

[Sam Hathaway]

I guess we’ll have to wait and see how things pan out.

¯\_(ツ)_/¯

On 11 Jan 2019, at 15:21, Randall Gellens wrote:

> On 11 Jan 2019, at 12:10, Sam Hathaway wrote:
>
>> On 11 Jan 2019, at 14:58, Randall Gellens wrote:
>>
>>> An IMAP-JMAP proxy just moves the complexity of dealing with the 
>>> myriad of IMAP servers from core MailMate to an embedded proxy.  I 
>>> don't see it providing that much help, while it would undoubtedly 
>>> introduce its own set of problems.
>>
>> If coordinated right, it would centralize the thankless work of 
>> kludging around nonstandard, broken IMAP server implementations. 
>> Imagine if, instead of each MUA author having to develop, test, and 
>> maintain dozens of ugly hacks, they were collaborating to improve a 
>> single JMAP proxy codebase that all could use.
>
> That could be a great thing.  Or it could be just one more variant for 
> a client to support, potentially multiple variants if the proxy 
> behaves differently depending on which IMAP server it is facing.  Done 
> well, a universal proxy could help.  But then, done well, IMAP is 
> fine.
>
>>> As I said earlier, while JMAP might be very cool, it doesn’t help 
>>> the core problem of widely variant IMAP server behavior; instead, it 
>>> just introduces yet more variants.
>>
>> It does move us towards solving the problem of IMAP being kinda trash 
>> for resource-constrained clients with slow network connections.
>
> As I mentioned before, IMAP was originally designed for extremely slow 
> dial-up lines that were prone to sudden disconnection.  Many of the 
> features of IMAP are specifically for the problems of communication in 
> that environment.
>
>> I think it’s telling that many of the major email providers 
>> (Google, Microsoft, and FastMail, at least) felt the need to create 
>> their own proprietary mail access protocols for use by their mobile 
>> apps. What this says to me is that IMAP is not fit-for-purpose when 
>> it comes to smartphone apps.
>
> Maybe, or maybe many of the big providers didn't want to spend the 
> time to figure out how to do IMAP well, and/or saw competitive 
> advantages of having their own protocol.  There's a long-standing 
> problem of players big and small doing poor jobs of implementing 
> standards.  In some cases, it was clear that developers read the RFC 
> examples but not the normative text.
>
> --Randall
> _______________________________________________
> mailmate mailing list
> mailmate at lists.freron.com
> https://lists.freron.com/listinfo/mailmate