You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Vidar Ramdal <vi...@idium.no> on 2010/05/06 17:04:23 UTC

Re: Caching Support Request Filter

On Wed, Apr 28, 2010 at 5:23 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Now, taken a step further: do we really want to build a cache into
> Sling ? Shouldn't we rather rely on some existing caching proxy for
> this, like Squid or mod_cache/mod_proxy ?

Thinking about this a bit more; instead of building a cache mecanism
ourselves, how about providing a good integration point for caching
proxies?

This component would be a filter or similar, which must track which
resources are being accessed during a request. The component would
register as a resource event listener, to be notified when resources
are changed, so that the corresponding request URIs can be
invalidated.
When invalidating a request URI, the component should call a pluggable
adapter (e.g. a SquidAdapter), which in turn will notify Squid of the
invalidation.

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: Caching Support Request Filter

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 06.05.2010 16:04, Vidar Ramdal wrote:
> On Wed, Apr 28, 2010 at 5:23 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Now, taken a step further: do we really want to build a cache into
>> Sling ? Shouldn't we rather rely on some existing caching proxy for
>> this, like Squid or mod_cache/mod_proxy ?
> 
> Thinking about this a bit more; instead of building a cache mecanism
> ourselves, how about providing a good integration point for caching
> proxies?
> 
> This component would be a filter or similar, which must track which
> resources are being accessed during a request. The component would
> register as a resource event listener, to be notified when resources
> are changed, so that the corresponding request URIs can be
> invalidated.
> When invalidating a request URI, the component should call a pluggable
> adapter (e.g. a SquidAdapter), which in turn will notify Squid of the
> invalidation.

Exactly, what I had in mind ;-)

And since all resources are accessed through the request's
ResourceResolver, it would probably be easiest to track these accesses
in the resource resolver and make it available to the cache
infrastructure ...

Regards
Felix