On Wed, Jul 20, 2016 at 9:43 AM, Neil Jenkins <[email protected]> wrote: > The reason we have position+limit (and the total is always returned) is so > that a client can simulate having the whole mailbox loaded, without actually > having to load the whole mailbox.
Thanks for the explanation. Make sense to me. > contacts will often be loaded in their > entirety so the client can find the index, [...] the need to expand [calendar > event] > recurrences client-side anyway makes the index in the list less useful in > general). This is why I fail to see the benefit of offset-based paging for contacts and calendar events, Of course, being consistent across object type search might be a good enough argument not to use token style paging. Yet, from your experience having implemented a JMAP client for all object types is there really a use-case for server-side, offset-based paging for contacts or calendar events (that's a genuine question, no subtlety here)? Token-based pagination looks like a more lightweight scheme for both clients and servers, and doesn't seem to dictate as many implementation details, but I might be mistaken here. Any way, I'd be happy to see it in the spec but am not pushing for it. There's always the option to fall back to a x-nextPageToken property for tightly bound client and server implementations that might benefit from it. Cheers, Robert -- 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/CABvA2aiSeSPN-CgivttYbYfGHuGMX7FaHbhx3gC_fJUV%2BFGVRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
