cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [RT] Cocoon in cacheland
Date Wed, 29 Nov 2000 08:48:29 GMT

--- Paul Russell <> wrote:
> Can we define some terms here guys - I think we need to be
> absolutely crystal clear what we're talking about, otherwise
> it's all meaningless:
> * Cache
>   A collection of resources (that is data) upon which the Cocoon
>   code operates.
>   There are several types of cache:
>   1) XML stream caches
>      Cache XML streams INSIDE the pipeline.

These are SAX events (only to be clear :)

>   2) Serialized data caches
>      Cache the results of a request OUTSIDE the pipeline.

These are byte streams.

>   3) Independant cache
>      (can anyone think of a better name? this one is horribly
>      ambiguous)
>      A cache contained and maintained within a component.

Someone else here called it a 'component private cache'. But see my
comments below.

> * Pool
>   A collection of objects implementing part of the cocoon
>   pipeline and/or architecture which are instantiated on
>   demand, but returned to the pool of active components
>   when their (one off) execution is complete.

And more precicely: a pool contains objects of the same type (ie.
FileGenerator). So we have as many pools as we have Components
implementing the Poolable/Recyclable interface.

>   There are several types of these, too:
>   1) Main cocoon component pools.
>      For caching component instances not directly related
>      to the operation of the sitemap instance.

These are the components defined in the cocoon.xconf file.

>   2) Sitemap component pools.
>      For caching component instances used within the sitemap
>      pipeline.

These are the components defined in the components section of
sitemap.xmap files. 

>   3) Independant pools
>      Pools of component instances maintained and contained
>      within a component. (this is the type of pool which
>      would contain the Xalan stylesheet instances)

There is also a third kind of cache/pool which we call Store. The store
in defined in the general components (cocoon.xconf) and is used to put
objects into it of different kind. Each Component can implement the
Composer interface to have a ComponentManager available to get at the
defined Store which it can use to get/put his very own objects into it
(ie compiled stylesheets). This IMO is where individual objects/classes
should maintain their 'private cache'.

> Although the framework should not concern itself directly with
> independant pools and caches, it should provide support classes
> to assist developers wishing to use independant caches or pools.

See above. This is IMO what the Store interface is for.

> Note that at this stage we're not saying we WILL support
> any of these or all of these. As the discussion progesses,
> it should become clear.
> Does this terminology make sense to everyone? Anyone got
> any better ideas for words to describe their functions?

Sound clear to me now.



Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.

View raw message