Document that state strings SHOULD persist for a decent time period (e.g. 1 month)

[brong]

3.10.1 getFoos

state: need to specify scope and duration of this string. I'd guess it is scoped to the specific getFoos request, so there's no requirement for portability of this state token to other users or types. But it'd be better if it's quite persistent (e.g., lasts a month or until the client issues an update).

If the cannotCalculateChanges error occurs too frequently, the server becomes problematic for client performance. A quality server should strive to persist state tokens for several clients per user for at least a month.

[filipnavara]

As long as it is a SHOULD requirement than I would very much welcome that [with my client writer hat on].

As a server writer, working with legacy backend thought me that the performance improvement of simply being able to determine if anything changed since the last sync at all is a notable performance improvement by itself. On resources that change infrequently (eg. personal calendars) we returned cannotCalculateChanges (or equivalent in other protocols) after any change and returned empty response when no change occurred. It saved a lot of network traffic and computing resources. It was worth it for both the server and the clients. Furthermore, this implementation allowed the "state" to consist only of the highest modification time and the number of items. Both of which could be calculated from existing data without keeping any log.

[brong]

Absolutely, I would also push back very hard against a MUST. Your design makes a lot of sense, and maps nicely to the etag style of HTTP "If-Not-Modified". Bron.

…

On Wed, 19 Jul 2017, at 21:03, Filip Navara wrote: As long as it is a SHOULD requirement than I would very much welcome that [with my client writer hat on].> As a server writer, working with legacy backend thought me that the performance improvement of simply being able to determine if anything changed since the last sync at all is a notable performance improvement by itself. On resources that change infrequently (eg. personal calendars) we returned cannotCalculateChanges (or equivalent in other protocols) after any change and returned empty response when no change occurred. It saved a lot of network traffic and computing resources. It was worth it for both the server and the clients. Furthermore, this implementation allowed the "state" to consist only of the highest modification time and the number of items. Both of which could be calculated from existing data without keeping any log.> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub[1], or mute the thread[2]. >

-- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com Links: 1. #119 (comment) 2. https://github.com/notifications/unsubscribe-auth/AABE7Tnav2BgcO1PgV0wzDc9WPy4hJFfks5sPeKLgaJpZM4OcUB-