Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 08 May 2017 13:31 UTC

Return-Path: <alexey.melnikov@isode.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 2ECDF129478 for <jmap@ietfa.amsl.com>; Mon, 8 May 2017 06:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 hBXpC2Ln4eWO for <jmap@ietfa.amsl.com>; Mon, 8 May 2017 06:31:30 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5EC129473 for <jmap@ietf.org>; Mon, 8 May 2017 06:31:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494250289; d=isode.com; s=june2016; i=@isode.com; bh=2JTAfSKbimib7imzHzWFyKUwkBfzqHjZboHpCc5L1dM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Nt9ngPU4KSpAmS6q47uOt85eFbcgadBfcXpHLPjt0VtYMs9zCoiDcirEf6BCYK57znjPCV j3WY3Dr6O6PimAS51LNQ06D0Z6CX6rp+ZiIauXB2bNwGe72IuD/Ytx1XmrN8BXm4uEPOqo 2sAkBjjbegzH2ojidOP3xNvBvOoQnqk=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <WRBzMQAOgVcQ@statler.isode.com>; Mon, 8 May 2017 14:31:29 +0100
To: Neil Jenkins <neilj@fastmail.com>, jmap@ietf.org
References: <20170507123912.GA22520@snake.grepular.com> <FF749B75-173D-4086-BAE6-AFB897D5F676@fugue.com> <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <3e948365-a783-adc5-13c4-906628159dc6@isode.com>
Date: Mon, 08 May 2017 14:31:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
In-Reply-To: <1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------498C66627DE1DF267F6BFA6A"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/GZrFQ-jmyhruq-cF6biGtZ_uFcI>
Subject: Re: [Jmap] Hacker News Discussion - getMailboxes single data set vs tree primitives or paging
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, 08 May 2017 13:31:32 -0000

Hi Neil,

On 08/05/2017 07:19, Neil Jenkins wrote:

> When considering this before, I've tended to observe the following points:
>
>   * Standard mail clients generally fetch all mailboxes up front, and
>     indeed often need to before they will display a (non-loading) UI.
>   * The vast majority of users have very few folders (from what I
>     remember last time we ran the stats at FastMail, well over 90% of
>     users never created a single extra folder beyond the defaults).
>
>
> So I therefore left out querying mailboxes (and so being able to fetch 
> them in pages) from the initial JMAP draft. The main case for this 
> seems to be presenting access to usenet groups or other 
> non-strictly-email stuff. There is always a question of whether we 
> want to support every use case, at the expense of making 
> implementation more onerous.
Isode implemented a client that listed mailboxes level by level, due to 
constraint bandwidth.

We also have several thousands of shared mailboxes (they have nothing to 
do with Usenet), I think some enterprise type deployments will be 
similar. So having a way of listing direct children and all descendants 
of a mailbox would be very useful for us.
> Having said that, there's a standard mechanism in JMAP for doing 
> querying/sorting/paging of a record type (getFooList 
> <http://jmap.io/spec-core.html#querying-data>), so if we do decide we 
> want this capability it is mostly obvious how it should be specified. 
> We'd include a filter option for /parentId/ so you could easily fetch 
> as a hierarchy if you want, and it would be easy to add an isArchived 
> flag or similar later and filter on that if desired.
>
> As long as we still allow /getMailboxes/ to be called with a null 
> /ids/ argument (therefore returning all mailboxes), clients can still 
> just ignore all this if they always need to fetch the whole set up 
> front. It's mainly therefore an extra burden on server 
> implementations. So is it worth the tradeoff? Thoughts?
I already wrote the server code for IMAP, so not much of a burden on the 
server side.