Microformat updater: set cache header #246
Conversation
wiki.laptop.org, where the pages used to update the activities are located, usually serve old cached pages. We can avoid that setting the header Cache-Control' = 'max-age=600', and be sure the page is not older than 10 minutes. Signed-off-by: Gonzalo Odiard <godiard@sugarlabs.org>
|
Maybe I'm missing something but isn't this just a work around for a server issue? Since we control the server, I'd rather fix that. |
|
We were discussing this, and is not the case that we can control all the servers along the way. Therefore, We were thinking on alternatives on how to get a decent trade off between "clients getting updates sooner" and "servers not getting heavy traffic over resources that doesn't change very often". And this was a good alternative. |
|
Would this not have some effect at the schools that have to pass all the traffic through a proxy before reaching wiki.laptop.org? What if a deployment wanted to use an alternate location for the microformat webpage, such as on a schoolserver, would this change not effect that situation also? I'm with dnarvaez on this, it's a server side issue http://dev.laptop.org/ticket/10722, but does SL really have control over olpc's servers or the proxy in front of the server in question? |
|
No matter what we decide here, we should start providing a SL service for On Fri, Feb 14, 2014 at 11:07 AM, Jerry Vonau notifications@github.comwrote:
Walter Bender |
|
Changing client side code to compensate for a single website's behavior when the client side can be pointed to any other server just feels wrong to me. |
|
That is funny I don't see the conversation on IRC, was this in a private chat maybe? Perhaps this should be discussed on the mailinglists (both SL's sugar-devel and olpc's devel) to gather greater community input. |
|
@jvonau no, only a few requests (the first ones) each 10 minutes would need to reach the final server... the rest of the requests would simply use the cached version of the resource, as it is renewed. That is it a trade-off: the clients gets relatively new version of the resource while the servers can still cache most of the traffic. |
|
How about a "force" button added to control panel that would add the Cache-Content header on demand and retry in place of a wholesale change? The advantage is only one user would need to force the refresh of the cache for the rest of the other users using the same pathway through the same proxy. Think this might be a fair trade-off. |
|
Well, we did considerable work client side to have transparent automatic updates, I think we should keep the UX that way. As I said on IRC I'm fine with going with this if tch and gonzalo feels strongly that it's the way to go. Let's just add a comment explaining the rationale. From the current comment it's not clear why we couldn't just fix dev.laptop.org. |
|
Ok, pushed with a better description. |
wiki.laptop.org, where the pages used to update the activities are
located, usually serve old cached pages. We can avoid that
setting the header Cache-Control' = 'max-age=600',
and be sure the page is not older than 10 minutes.
Signed-off-by: Gonzalo Odiard godiard@sugarlabs.org