Subject: [Jmap] Making clients explicitly request totals.

From: Bron Gondwana <[email-masked]>
Date: Sun, 15 Jul 2018 10:07:26 +1000

(individual contributor hat)

One of the design properties we discussed right back at the start of the
JMAP effort was "don't make the server do any implicit work that the
client doesn't need".
A place in which we may not be meeting that well is the "total" field in
/query and /queryChanges responses.  In some cases, the server may have
a complete total, but in other cases it might be significant work,
particularly if it has to be a 100% accurate total.  Likewise getting a
perfect sort may sometimes be hard work, particularly if doing a
"relevance" sort or similarly fuzzy thing.  Or if there's duplicate
suppression or thread collapsing happening.
So...  I'd like to float the idea of having a calculateTotal: true
property on /query and /queryChanges, allowing a client to make a
request like "give me the first 30 items" without a total, and the
server can reply with either canCalculateChanges: false, or with a token
that allows it to know which 30 items it previously returned, such that
a request for the next page will get the right data.
Think of something like Hacker News or Reddit, where you're getting the
"first page" of items, and a token that allows you to get a next page
later, until that token goes stale a few hours later.
An alternative to having the client explicitly request totals is having
the client explicitly request a loosening of the requirement - that's a
philosophical question.  My preferred philosophy is "the client has to
ask for any work it wants the server to do", so default to not providing
totals - but I'm open to discussion.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 16 Jul 2018 04:18:31 +1000

You've got less than a day to reply to this if you aren't going to be at
Montreal and you want your comments mentioned during the session :)

Cheers,
Bron.

On Sun, Jul 15, 2018, at 10:07, Bron Gondwana wrote:
> One of the design properties we discussed right back at the start of
> the JMAP effort was "don't make the server do any implicit work that
> the client doesn't need".> 
> A place in which we may not be meeting that well is the "total" field
> in /query and /queryChanges responses.  In some cases, the server may
> have a complete total, but in other cases it might be significant
> work, particularly if it has to be a 100% accurate total.  Likewise
> getting a perfect sort may sometimes be hard work, particularly if
> doing a "relevance" sort or similarly fuzzy thing.  Or if there's
> duplicate suppression or thread collapsing happening.> 
> server can reply with either canCalculateChanges: false, or with a
> token that allows it to know which 30 items it previously returned,
> such that a request for the next page will get the right data.> 
> Think of something like Hacker News or Reddit, where you're getting
> the "first page" of items, and a token that allows you to get a next
> page later, until that token goes stale a few hours later.> 
> An alternative to having the client explicitly request totals is
> having the client explicitly request a loosening of the requirement -
> that's a philosophical question.  My preferred philosophy is "the
> client has to ask for any work it wants the server to do", so default
> to not providing totals - but I'm open to discussion.> 
> Bron.
> 
> 
> --
> _________________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 16 Jul 2018 02:47:15 -0400

I think this is reasonable, presuming it can allow significant performance wins when the client doesn't need the total. As long as the client can get the total when it needs it. I would imagine it would work something like this:
 * If fast to compute (i.e. cached) the server always returns the total in the query or queryChanges response (this avoids the client making a future request for it when it was super cheap to return with the initial request anyway).
 * Otherwise, the total is returned as `null` unless specifically requested by a calculateTotal: true argument to the methods.

> Likewise getting a perfect sort may sometimes be hard work, particularly if doing a "relevance" sort or similarly fuzzy thing.  Or if there's duplicate suppression or thread collapsing happening.

I'm unclear exactly what you're referring to here, or how it's relevant to the proposal. Thread collapsing happens *after* sorting.  The proposal does allow you to avoid a lot of the work of collapsing if just requesting the first X results. But it doesn't let you avoid sorting, as you need this to determine which results are the *first* X.

> the server can reply with either canCalculateChanges: false, or with a token that allows it to know which 30 items it previously returned, such that a request for the next page will get the right data.
> 
> Think of something like Hacker News or Reddit, where you're getting the "first page" of items, and a token that allows you to get a next page later, until that token goes stale a few hours later.

Are you proposing something different to the existing queryState string and changes mechanism? If so, what and why? It seems to me this should "just work" without any changes to the spec (other than requiring explicit opt-in from the client to force /queryChanges to return the exact total, as with /query)?

Neil.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 16 Jul 2018 09:39:54 +0200

Please: Fewer cases to test.

"Do it if cheap" and such add complexity, and I don't see that justified. 
IMAP should have taught us all the value of having grokkable server 
behaviour.

Aside from that, I don't see any justification for having total be a 
special case. Deviating from the protocol's general principles is fine 
whenever  there's a reason to, I don't see a reason to deviate for totals. 
"It may require few CPU cycles" is an opportunity, not a reason.

Arnt