Nice thing Ian, I'll try to have a look at it and look to add DirectMemory impl 
to it as soon as I can.
Thanks and regards,
Tommaso



On 29/ott/2012, at 11:04, Ian Boston wrote:

> Earlier today I pushed an API bundle and impl for EhCache and Infinispan to
> SVN under whiteboard/ieb/cache (whiteboard is at the same level as trunk in
> SVN). I haven't actually started either bundle in an Osgi container yet, so
> there may be some issues. The commit history on the code that was ported
> looks clean. There are notes in the readme files.
> 
> I will have a look at that and implementing the portal cache API tomorrow
> in a spare moment.
> Ian
> 
> On Monday, October 29, 2012, Antonio Sanso wrote:
> 
>> +1
>> 
>> Antonio
>> 
>> On Oct 27, 2012, at 12:10 AM, Ian Boston wrote:
>> 
>>> Hi,
>>> 
>>> In [1] there is some discussion about  a caching bundle. The use case
>>> (or user story if you like) is to allow applications written in Sling
>>> to have a centralised place where they can cache things. There is
>>> already an API in the portlet bundle that provides caching for
>>> portlets, but it seems there is a  wider use case, which covers object
>>> caching outside the core repository itself and page fragment caching.
>>> 
>>> Since I have come across this use case before in Sling, I have a
>>> bundle that worked for me in the past[2]. Subject to checking that its
>>> clean from an IPR and (c) perspective and getting permission from any
>>> authors that might have created fragments of code within that bundle I
>>> was thinking of bringing it into the whiteboard area to see if it
>>> could be adapted to meet everyones needs.
>>> 
>>> WDYT ?
>>> 
>>> Ian
>>> 
>>> 
>>> 
>>> 1 https://issues.apache.org/jira/browse/SLING-2555
>>> 2
>> https://github.com/ieb/sparsemapcontent/tree/master/extensions/memory/src/main/java/org/sakaiproject/nakamura/api/memory
>>> which was ported from
>>> 
>> https://github.com/sakaiproject/nakamura/tree/b9d8e65b733ec7c35a3d194c9a5dc12acf13cb34/bundles/memory
>>> on September 26 2011.
>>> The commit log appears to be clean.
>> 
>> 

Reply via email to