[Jmap] Best vs Good enough - adoption of JMAP
"Adrien de Croy" <adrien@qbik.com> Mon, 24 April 2017 22:43 UTC
Return-Path: <adrien@qbik.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DF2131953 for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 15:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Ra0iSzvvfc for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 15:43:27 -0700 (PDT)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141FB131954 for <jmap@ietf.org>; Mon, 24 Apr 2017 15:43:26 -0700 (PDT)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001028965@smtp.qbik.com>; Tue, 25 Apr 2017 10:43:24 +1200
From: Adrien de Croy <adrien@qbik.com>
To: "jmap@ietf.org" <jmap@ietf.org>
Date: Mon, 24 Apr 2017 22:43:24 +0000
Message-Id: <em8b177018-4769-44ea-b033-90bd8155d11b@bodybag>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/7.0.27943.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB798A9939-F3B3-442A-8A1E-927D711702DC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/LPEKhVA6kcGR0C0cHrG5BBERNPA>
Subject: [Jmap] Best vs Good enough - adoption of JMAP
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 22:43:29 -0000
On the topic of best vs good enough. I agree they are perhaps opposed, you could say that good enough is the enemy of best however, since once you have something that is good enough, your incentive to do any better is greatly diminished. However, we are up against several obstacles when it comes to adoption of JMAP. 1. Server authors won't want to add support unless there are clients 2. Client authors won't want to add support unless there are servers 3. Client or server authors won't want to add support unless they can make things significantly better for mail users. 4. We are losing customers to alternate messaging systems. If our target is just going to end up providing no benefits to users over what we already have with IMAP+SMTP, then nobody will bother. Where it gets interesting for me personally at least is if we can push the boundary of mail experience. In many cases this can be done in the MUA but in some cases it requires support from the protocols. I hear the arguments that the more complex we make the spec, the less likely it will be implemented, at least correctly. I'm not a fan of complexity either, and neither of my suggestions do I consider to be particularly complex. My argument is that if the design doesn't hold out a carrot for better mail experience for users, then nobody will bother, and we're wasting our time here, which would be a shame because we have the potential to achieve a lot here. At the moment, there is a benefit on the table, mostly being the ability to only require configuration of access to 1 service (that's if JMAP does submission). I believe we should be looking for opportunities to make mail the best experience possible, come up with ideas, and we may decided to defer some or not implement others, but we should keep them in mind so that perhaps we don't close off the path to some of them. We don't need another protocol that is hamstrung by lack of foresight. there are plenty of ideas around, look at the competition. Cheers Adrien
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ted Lemon
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ted Lemon
- [Jmap] Best vs Good enough - adoption of JMAP Adrien de Croy
- Re: [Jmap] Best vs Good enough - adoption of JMAP Bron Gondwana
- Re: [Jmap] Best vs Good enough - adoption of JMAP Bron Gondwana
- Re: [Jmap] Best vs Good enough - adoption of JMAP Chris Newman
- Re: [Jmap] Best vs Good enough - adoption of JMAP Neil Jenkins
- Re: [Jmap] Best vs Good enough - adoption of JMAP Chris Newman
- Re: [Jmap] Best vs Good enough - adoption of JMAP Adrien de Croy
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ted Lemon
- Re: [Jmap] Best vs Good enough - adoption of JMAP Chris Newman
- Re: [Jmap] Best vs Good enough - adoption of JMAP Neil Jenkins
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ted Lemon
- Re: [Jmap] Best vs Good enough - adoption of JMAP Chris Newman
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ned Freed
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ted Lemon
- Re: [Jmap] Best vs Good enough - adoption of JMAP Bron Gondwana
- Re: [Jmap] Best vs Good enough - adoption of JMAP Chris Newman
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ned Freed
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ned Freed
- Re: [Jmap] simpler future release & unsend withou… Ted Lemon
- [Jmap] simpler future release & unsend without ou… Chris Newman
- Re: [Jmap] Best vs Good enough - adoption of JMAP Neil Jenkins
- Re: [Jmap] Best vs Good enough - adoption of JMAP Brandon Long
- Re: [Jmap] Best vs Good enough - adoption of JMAP Brandon Long
- Re: [Jmap] simpler future release & unsend withou… Chris Newman
- Re: [Jmap] simpler future release & unsend withou… Neil Jenkins
- Re: [Jmap] Best vs Good enough - adoption of JMAP Chris Newman
- Re: [Jmap] simpler future release & unsend withou… Neil Jenkins
- Re: [Jmap] simpler future release & unsend withou… Neil Jenkins
- Re: [Jmap] simpler future release & unsend withou… Adrien de Croy
- Re: [Jmap] simpler future release & unsend withou… Adrien de Croy
- Re: [Jmap] Best vs Good enough - adoption of JMAP Ned Freed
- Re: [Jmap] simpler future release & unsend withou… Ned Freed
- Re: [Jmap] simpler future release & unsend withou… Neil Jenkins
- Re: [Jmap] simpler future release & unsend withou… Chris Newman
- Re: [Jmap] simpler future release & unsend withou… Neil Jenkins
- Re: [Jmap] simpler future release & unsend withou… Ted Lemon
- Re: [Jmap] simpler future release & unsend withou… Chris Newman
- Re: [Jmap] simpler future release & unsend withou… ajay
- Re: [Jmap] simpler future release & unsend withou… xn--l1b0cxc
- Re: [Jmap] simpler future release & unsend withou… xn--l1b0cxc
- Re: [Jmap] simpler future release & unsend withou… Neil Jenkins