info/collections and meta/global 304s
Richard Newman
> If we don't already do it, we should take advantage of more opportunities to send less data: for example, sending 304 Not Modified in response to info and meta requests. In a world of instant syncs, this might avoid schlepping a non-trivial number of bytes over the wire, and some client parsing too.
mconnor hadn't heard this, so he asked me to send out a note.
At the start of each sync, a client requests info/collections. The server hits memcache, pulls timestamps for each collections, and sends back a JSON response. The client parses this and checks each timestamp to decide what it needs to do.
The more frequently a client syncs, the less likely it is that anything has changed. We eventually want to reach a world where Android Sync can be pinging the server every 30 seconds without touching its own persistent storage or bringing down our infrastructure, so shortening this chain could be a win.
It seems like a reasonable optimization to track the high-watermark timestamp whenever a collection modified time is changed. Return this with an info/collections 200 response. The client can track it and pass it in with the next request. The server can then check a single value in info/collections, immediately returning a 304 if nothing has changed.
No fetching other values, no JSON serialization, and no parsing or additional work on the client (unless the client knows it needs to upload something, in which case it can still skip meta/global, key checks, downloading new records, and all the other bumpf that it normally does).
Combine this with the token proposal, and we could also optionally avoid issuing a token in this case.
Thoughts?
-R
_______________________________________________
Services-dev mailing list
Servic...@mozilla.org
https://mail.mozilla.org/listinfo/services-dev
Richard Newman
https://bugzilla.mozilla.org/show_bug.cgi?id=736370
and will file bugs in individual components to get action.
Thanks!