probably needs to be exposed as a property for engines, defaulting to never expire.

Probably best to hang this off the type records as they are the ones that know how to JSONify themselves to a WBO (which would include the TTL information).

We haven't officially documented the TTL stuff yet, but as far as I can tell, it's a numeric attribute of the WBO called 'ttl' expressing a UNIX timestamp (seconds) of when the object expires. Absence or a value >= 2100000000 means it lives forever. History entries TTLs should live for 30 days from their last modification. What values do we want for form history and clients/tabs?

This is needed so quotas don't completely suck.

Would this really hold a time-based released? Why can't it wait for the next beta? Moving to betaN

Make WBO sane and more unit-y: * don't test HTTP auth at the same time * use fetch() method if we're talking over the wire at all * move common HTTP test helper to head file * clean up unnecessary do_throw() calls * use common helpers for test logging

Add a TTL property to WBOs. If engine record implementations have a 'ttl' attribute, it gets included in the WBO. Add default TTLs: * clients: 7 days * tabs: 7 days * history: 30 days In part 2 (TBD) the client engine will need to make sure to update its server record at least once a week.

Use a TTL of 21 days for client records.

The TTL for client records is 21 days so we make sure that we upload a new client record every 7 days.

Comment on attachment 502950 [details] [diff] [review] Part 1 (v1.1): Add ttl property to WBOs > ClientsRec.prototype = { > __proto__: CryptoWrapper.prototype, > _logName: "Record.Clients", >+ // 21 days >+ ttl: 1814400 Error: Magic number detected. 3 additional copies of this error reported. (Please make these consts, since I suspect we'll tune these values at some point.) We'll probably want a crossweave test for this at some point.

Comment on attachment 502951 [details] [diff] [review] Part 2 (v1): Clients engine needs to periodically upload new record >+ _syncStartup: function _syncStartup() { >+ // Reupload new client record after 7 days. >+ if (Date.now() / 1000 - this.lastRecordUpload > 604800) { another magic number. I thought i raised you better than that.

Incorporate review comment: move numbers to consts.

Incorporate review comment: move numbers to consts.

There was IRC talk about having history TTLs of 60 days rather than 30 days. Can we get a decision on this? Other than that this is ready for landing.

We're going to go with 60 days to start. Ship it!

1.6.x: Part 0: https://hg.mozilla.org/services/fx-sync/rev/5289b58f2c4a Part 1: https://hg.mozilla.org/services/fx-sync/rev/b8d357f848c4 Part 2: https://hg.mozilla.org/services/fx-sync/rev/23dc83bca24e default: Part 0: https://hg.mozilla.org/services/fx-sync/rev/7e64c61313be Part 1: https://hg.mozilla.org/services/fx-sync/rev/3701ffdc6c0e Part 2: https://hg.mozilla.org/services/fx-sync/rev/4ca4c048cbb9

Backed out from 1.6.x, was not meant to go there: https://hg.mozilla.org/services/fx-sync/rev/e34a3410f235