[Deploying Sakai] OAE UI Caching

[Andrew Petro]

On review I was wrong about how this works.  There's a 
"resource-aggregator", distinct from the resource serving webapp, and it 
should have been the aggregator I referenced, though it turns out it has 
some critical limitations for Sakai's present purposes.

This ends up being a red herring for purposes of the original question 
and for the scope of this email list, but I'll post this reply here to 
close the loop.  Presumably any dev work to close this gap and re-use 
this library in Sakai should be undertaken on a dev list.




To the extent that the below is valuable, I'm channeling what Jen told 
me about this today.  To the extent that it's still wrong, that's me. :

There are two interesting technologies here.  One of them is the 
Resource Serving Webapp and associated tag library.  The other is 
build-time compression and hashing of resources.

With regard to the resource serving webapp:

This isn't portlet-specific or portlet-related.  Any servlet-based app with an architecture that includes multiple related web contexts in a single servlet container would benefit.  There are appropriate cache headers set, though the real point of the project here is to provide a good way to have a consistent URL for resources that are used by multiple webapps to take advantage of browser caching.  In general it would be quite relevant to Sakai, and I think shares some intentions with the reference/library path?.

The resource serving webapp is centered around serving up canonical versions of canonical libraries in a canonical, and at-most-once, way. The resource server is more akin to something like Google's CDN that serves up jQuery and other heavily used libraries.  The resource server is really specifically targeted to external, well-defined libraries that are shared across multiple projects and already have tagged releases.

The part of the story where resources are compressed and hashed with aggressive cache headers and reliance on different hashes yielding cache misses for browser cache refresh, is a totally different problem solved in uPortal with different technology.


And here I'll just quote Jen verbatim:

[
As part of the uPortal build process, we ask maven to take a bunch of js/css resources, aggregate them all together, minify them, and stick a hash code in the name.  That minified, aggregated version gets long-term cache headers applied, but we also deploy all the original source files.  The code that includes all the js/css in the page looks for a JVM flag that indicates whether the aggregated/minified/cached version or the original versions should be used, so that we don't completely crush the souls of all the UX devs.

There's a lot of really terrific code in that section of the project (resource-aggregator in the Jasig sandbox) and it'll eventually be a good resource for any servlet-based project (not just portlets).  Unfortunately the key piece that includes the resources in the page is still XSLT-specific, so this isn't yet technology that can be adopted by not-uPortal projects without having to write some custom code.  We definitely intend to write a JSP tag for this tech so that we can use it from portlets though, at which point it'd be more generally adoptable.

]

resource-aggregator:

https://source.jasig.org/sandbox/resource-aggregator/



On 8/22/2011 10:48 AM, csev wrote:
> Thanks Chris/Andrew.
>
> What I am having trouble figuring out is how a peer webapp calls some 
> sort of API to get the "cached URL".   am looking for the underlying 
> mechanism when a webapp is at the moment of generating markup and 
> needs to embed a URL to a seldom-changing artifact.
>
> This documentation from
>
> https://wiki.jasig.org/display/UPM40/Using+the+Resource+Server
>
> needs to be expanded if you really intend for this to be of general use:
>
> <rs:resourceURL var="jQueryPath" 
> value="/rs/jquery/1.3.1/jquery-1.3.1.js"/>
>
> What is the magic here?  Does this only work for JSR-168 portlets? 
>  That seems to be kind of limiting if true....
>
> Also when the documentation talks of generated paths,
>
> • /ResourceServingWebapp/rs/jquery/1.3.1/jquery-1.3.1.js
>
> I wonder why there is not some number there having to do with the 
> contents of the file.
>
> I would bet that my confusion is just a lack of documentation to use 
> the webapp in a non-uPortal environment.
>
> /Chuck
>
>
> On Aug 19, 2011, at 4:07 PM, Andrew Petro wrote:
>
>> Chuck,
>>
>> Here's where the code lives:
>>
>> https://source.jasig.org/resource-server/
>>
>> Modern uPortal ships using it (i.e., not just the forthcoming uPortal 
>> 4 -- this is in uPortal 3.2 e.g.), so it should be pretty feasible to 
>> try it out in action.
>>
>> I think Jen Bourey knows more about this code than anyone.  She's out 
>> of reach on a well-deserved camping trip at this time, but you might 
>> reach out to her about it if interested.  Eric Dalquist should also 
>> be able to speak authoritatively to that code.
>>
>> I think the intent is that this is freestanding, re-usable, 
>> not-uPortal-specific infrastructure.  As in, to the extent that 
>> simple variations are needed to make this work well in Sakai 2.9, may 
>> be worth hearing about and pushing back into the resource server 
>> "product".
>>
>> Andrew
>>
>>
>> On 08/19/2011 03:53 PM, csev wrote:
>>> Andrew - where is that code?   Some of the links on that page are 
>>> broken.   I might want to add a simple variation of that to Sakai 
>>> 2.9 - looks very cool.
>>>
>>> /Chuck
>>>
>>> On Aug 19, 2011, at 2:48 PM, Andrew Petro wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>> https://wiki.jasig.org/display/UPM40/Using+the+Resource+Server
>>>>
>>>> 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.
>>>>
>>>> Andrew
>>>
>>
>> _______________________________________________
>> production mailing list
>> production at collab.sakaiproject.org 
>> <mailto:production at collab.sakaiproject.org>
>> http://collab.sakaiproject.org/mailman/listinfo/production
>>
>> TO UNSUBSCRIBE: send email to 
>> production-unsubscribe at collab.sakaiproject.org with a subject of 
>> "unsubscribe"
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20110822/72ce3368/attachment.html