incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <reto.bachm...@trialox.org>
Subject Re: Caching in .ssp
Date Sat, 11 Sep 2010 15:00:30 GMT
Hi Manuel,

in seedsnipe we have rendering functions which could be provided by services. An approach
would be provide such renderin functions in ssp. 

I don't think using the map for rendering process variables would be the right place. Rather
a separate map for those fumctions.

Cheers,
Reto

----- Original message -----
> 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