This is not ripe for a pull request, but I'd like to instigate discussion about getFooList pagination.
Currently, all getFooList methods define a position and limit property (and their responses a total) to allow clients to paginate search results. That's vanilla pagination, but it has the drawback that in order to compute page x, all x-1 search results must be (re)determined. Servers might try to cache search results, with all the burdens of statefulness. In contrast, a nextPageToken might help server implementations to reduce search space and speed up response time without keeping state. A nice write-up for this method is here: http://use-the-index-luke.com/no-offset If there is willingness to support this for the getFooList methods, off the top of my head I'd see these options: - Add nextPageToken as properties to both the requests and responses. A null pageToken indicates the first page for requests, and the end of pages in the response. Clients may choose to use either offset-based or keyset pagination. - Same as first option, but deprecate offset-based pagination.This would work under the assumption, that clients do not arbitrarily choose positions and limits, but cycle through pages from start to finish. In this case, existing server implementation could calculate their nextPageToken with the total index of the first element in the current page plus limit. (*) Note that the getMessageList method already defines two different pagination types (position and anchors) whereas contacts and calendarEvents only support offset-based pagination. I understand (and appreciate) the ambition to keep the spec small, but I wonder if the current offset-based pagination isn't unnecessarily restrictive for implementations. What do you think? (*) Disclaimer: I haven't prototyped this yet, so behind this alluring scheme might be a serious flaw lurking. -- You received this message because you are subscribed to the Google Groups "JMAP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/0d4cddcb-37e0-49e5-bda4-1ab81e367b93%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
