736370 - [meta] Protocol 2.0: return 304 when info/collections and meta/global are unchanged

Status: RESOLVED WONTFIX

(Cloud Services :: General, defect)

Description

[Richard Newman [:rnewman]]

See https://groups.google.com/forum/?fromgroups#!topic/mozilla-services-dev/YPJNcHpSZ18:

A long time ago, I dumped this in the "Protocol 2.0" wiki page.

> 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?

Comment 1

[Ryan Kelly [:rfkelly]]

This is now formalized as part of the Sync2.0 spec, closing the bug.

Comment 2

[Ryan Kelly [:rfkelly]]

Err, I'm an idiot who didn't read [meta] in the bug title, reopening for tracking the client-side implementation...

Comment 3

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

WONTFIX'ing for cleanup. Re-open if this is still (somehow) an issue after all this time...