Hi Ben,

Jackrabbit used to come with bundle cache which does exactly what you say, not 
knowing anything about the tree structure. And that stupidity is its strength: 
no need for a smart developer
to do pin point configuration of a tree or a single path. Things that are 
really used a lot were cached, the only configuration you do is on the size of 
the cache. I’m pretty sure similar mechanism exists with oak.

Now helping the stupid persistence caching by caching at the “application” 
layer things you, as an application developer, know they will be used a lot is 
always a good idea. Not sure this needs a framework though.

Nicolas

On 29 Jul 2014, at 08:15, Ben Zahler <[email protected]> wrote:

> Hi all,
> 
> We are considering to implement a resource-based caching in Sling.
> 
> I have found some efforts to do something similar in the past, but they all 
> seem to have been either abandoned or do something different from what we 
> have in mind.
> 
> So it would be great to get some feedback if it this has been tried before 
> and was given up or if our idea is just not what the Sling-world is waiting 
> for.
> 
> This is what our Sling-Cache would do:
> 
> -       deliver sling resources from cache based on an exact path
> 
> -       deliver sling resources from cache for a subtree of the repository
> 
> The following scenarios would benefit from such a cache:
> 
> -       navigation components that are expensive to calculate and are 
> identical for whole subtrees of a site
> 
> -       cacheable components on non-caheable pages
> 
> -       CQ use cases with dispatcher caching invalidate the large sections or 
> the whole cache. After an invalidation, for a short time all traffic hits 
> CQ/Sling. With resource based caching, this could be improved, allowing Sling 
> to scale better.
> 
> Of course we would create an open-source implementation of our idea, caching 
> either in memory or in the repository itself and leave room for other 
> implementations with external caches.
> 
> So is this an idea you would love to see implemented or is it rather 
> something that you deem unnecessarily complex?
> 
> Thanks for any feedback!
> 
> Cheers,
> Ben Zahler
> 
> Inside Solutions AG | Bahnhofplatz 11 | 4410 Liestal | Schweiz
> Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
> http://www.inside-solutions.ch<http://www.inside-solutions.ch/>

Reply via email to