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, 8 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
Precedence: list


--------------498C66627DE1DF267F6BFA6A
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

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.




--------------498C66627DE1DF267F6BFA6A
Content-Type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p>Hi Neil,<br>
    </p>
    <p>On 08/05/2017 07:19, Neil Jenkins wrote:<br>
    </p>
    <blockquote
cite=3D"mid:1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.co=
m"
      type=3D"cite">
      <title></title>
      <div>When considering this before, I've tended to observe the
        following points:<br>
      </div>
      <ul>
        <li>Standard mail clients generally fetch all mailboxes up
          front, and indeed often need to before they will display a
          (non-loading) UI.<br>
        </li>
        <li>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).<br>
        </li>
      </ul>
      <div><br>
      </div>
      <div>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.<br>
      </div>
    </blockquote>
    Isode implemented a client that listed mailboxes level by level, due
    to constraint bandwidth.<br>
    <br>
    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.<br>
    <blockquote
cite=3D"mid:1494224344.1447245.969038872.78D5E02D@webmail.messagingengine.co=
m"
      type=3D"cite">
      <div>Having said that, there's a standard mechanism in JMAP for
        doing querying/sorting/paging of a record type (<a
          moz-do-not-send=3D"true"
          href=3D"http://jmap.io/spec-core.html#querying-data">getFooList</a=
>),
        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 <i>pare=
ntId</i>
        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.<br>
      </div>
      <div><br>
      </div>
      <div>As long as we still allow <i>getMailboxes</i> to be called
        with a null <i>ids</i>=A0argument (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?<br>
      </div>
    </blockquote>
    I already wrote the server code for IMAP, so not much of a burden on
    the server side.<br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------498C66627DE1DF267F6BFA6A--