This becomes especially viable if we extend the token validity period, at the risk of losing data in, e.g., a sent tab.
Let's do this, persisting in memory.
Priority: P3 → P2
rfkelly: I see that tokens are by default valid for 300 units, which I infer to be seconds. (This is not clear from http://docs.services.mozilla.com/token/apis.html, but that's a separate issue.) Android may kill a sync after 5 minutes. It's bad news to get killed midway through a sync; we definitely want to avoid that. So we should only re-use a cached token if it's good for at least 5 more minutes. The current 5 minute lifespan therefore makes this moot. How would you feel about bumping the life of a token to a longer duration, say 15 or 20 minutes? This will affect our token refresh story, but let's cross that bridge later.
> I see that tokens are by default valid for 300 units Tokenserver should be issuing tokens valid for 3600 seconds; if not, then perhaps that config change has not rolled out to prod yet. So yes, I feel pretty good about a longer token duration!
tracking-fennec: 30+ → +
Version: Firefox 29 → unspecified
This has value - less work to do for the client on each sync - but there are bigger fish to fry.
Assignee: nalexander → nobody
Priority: P2 → P3
(In reply to :Grisha Kruglov from comment #4) > This has value - less work to do for the client on each sync - but there are > bigger fish to fry. Counterpoint: it's been very helpful to know that Android Sync requests a fresh token from the token server every Sync. Really simplifies arguing about what's happening as the ops side of Sync changes configurations, etc. Counter-counterpoint: We do cache token server tokens on iOS, which has worked out okay.
You need to log in before you can comment on or make changes to this bug.