Sylvain Wallez wrote: > > Clarify the store semantics > --------------------------- > As we've seen below, the Store interface provides 3 roles: Store.ROLE, > Store.TRANSIENT_STORE and Store.PERSISTANT_STORE. But the problem is > that PERSISTANT is defined as equal to ROLE and we actually only have > two real roles. > > I propose to clearly distinguish the 3 roles and the associtated > semantics: > - Store.ROLE is the "general-purpose" store. A component that doesn't > care if the cache is transient or persistent should use this one. Being > general-purpose, it should be efficient but also swap old objects to > persistent storage. > > - Store.TRANSIENT_STORE should be used to keep objects that aren't > serializable but should be kept in memory as far as possible. The flush > strategy of this store should not be mixed with a limited-size MRU > policy of a persistent store front-end. > > - Store.PERSISTANT_STORE should be, as its name implies, only > persistant, with no memory front-end or whatsoever. > This was the basic idea of the three different roles, unfortunately due to lazyness :) Store.ROLE and Store.PERSISTANT_STORE were made equal. So, big +1.
> > Redefine Cocoon stores > ---------------------- <SNIP/> +1 One point about stores and caching. The cache is currently configurable which store it uses. So, the cache can be configured to use the Store, the persistent store, the transient store or the send-everything-per-email-to-admin-store. This allows to fine tune your caching; perhaps some pipelines want to use the transient store, some the persistent, some an own one etc. Carsten
