[Deploying Sakai] OAE UI Caching
apetro at unicon.net
Fri Aug 19 11:48:31 PDT 2011
For whatever it's worth:
Modern uPortal has a "Resource Serving Webapp" that compresses, computes
hashes on, and sets aggressive caching headers for, cacheable UI
content. When items are changed, the hashes change, so the names
change, so browsers don't rely upon their caches.
As I understand it, it works well and, yes, borders on the magical.
This is probably more technology that Sakai-OAE-as-product might
consider incorporating rather than technology to be grafted on by a
production adopter, but either way I hope you find it a worthwhile lead.
On 8/18/2011 4:36 AM, Daniel Parry wrote:
> Sent this to UI dev but wondering if it might be better sent here:
> So we've been trying to figure out what to do with the UI,
> caching, and handling application upgrades. As the code currently
> stands, it seems like we'd need to tell all our users to "clear
> their cache" every time we do an upgrade, which will potentially
> be a helpdesk problem eventually with aggressive browser caching
> proxies, etc.
> I think there is some thought going on as to how to solve this
> from a UI perspective, though this is seeming quite a tricky
> problem and the thread seemed to stop at the end of July? If a
> (magic) fix doesn't come through in time for our go live and
> upgrades, we're kicking around the idea of using new CNAMEs every
> time we do a code upgrade and putting in appropriate redirects
> from the old CNAMEs:
> Thus, browsers will see the new host and refetch the code every
> time we upgrade. Not ideal from an operations perspective, but
> probably doable especially if upgrades don't fly in thick and
> Wondered if any other institutions have been brainstorming on this
> at all or have any thoughts on the matter, or even some magic :)?
> Best wishes,
More information about the production