incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Innerhofer <manuel.innerho...@trialox.org>
Subject Re: Caching in .ssp
Date Sat, 11 Sep 2010 14:22:22 GMT
Hi Reto,

Sorry, my previous mail seems to be ambiguous. My proposal was not about a
caching mechanism itself,
but a way to provide it to a ssp. As you say ssps cannot access OSGi
services. I propose to circumvent
this by filling services (implementing a certaing service interface) into
the global map. This would be done
by the GenericGraphNodeMBW which would reference the services to be filled
in. The caching service would
be just one instance of such a service, but with this mechanism all kinds of
services could be provided to
ssps (E.g. the script executor).

As for the caching mechanism itself. I implemented a generic way for caching
in org.clerezza.cms.cache.
With it it should possible to realize the features you described.

Cheers,
Manuel

On Sat, Sep 11, 2010 at 12:43 PM, Reto Bachmann-Gmuer <reto@trialox.org>wrote:

> Hi Manuel
>
> If I understand you correctly your proposal is about caching arbitrary
> java objects that would otherwise need to be generated multiple time.
>
> This is relevant for ScalaServerPages as these cannot access OSGi
> services directly which could otherwise take care of computation of
> the objects as well as appropriate caching. I think for ssps and other
> renderlets we should introduce mechanism that allow caching of the
> resulting snippet. A renderlet should be able to indicated how long
> the result it generates is valid and also which modifications to an
> underlying graph causes the otherwise cacheable result to be
> invalidated.
>
> Before addressing this issue I think we should:
> - select the renderlet based on a global type priority list (same as
> for typerendering), generate this typepriority list taking into
> account ordering constraints (provided typically by bundles) in a
> similar fashion as the ordering of documentation
>
> And maybe also:
> - make it easier to register ssps (withouit needing service call) and
> have them as well as statically served file easily overwritable at
> runtime (preventing the need of redeploys when fine-tuning the
> frontend).
>
> Cheers,
> reto
>
> On Thu, Sep 9, 2010 at 2:22 PM, Manuel Innerhofer <manuel@trialox.org>
> wrote:
> > Hi Reto,
> >
> > As you know, we want to use caching within a .ssp. We are thinking right
> now
> > about implementing the cache using static methods, which is unfavorable
> in
> > my opinion. I was thinking about another mechanism to provide a cache
> object
> > to the .ssp and I'd like to hear your opinion on an idea I came up
> with. You
> > recently implemented the global map
> > (https://issues.apache.org/jira/browse/CLEREZZA-271). I thought we could
> > pre-fill the global map with objects (e.g. the cache object). These
> objects
> > would implement a certain interface (something like
> > GlobalTypeRenderingObject) and expose themselves as OSGi services. The
> > GenericGraphNodeMBW would reference these services and fill them into the
> > global map.
> > What do you think? Of course the input of everyone is welcome!
> >
> > Cheers,
> > Manuel
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message