cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Rolappe" <m_rola...@web.de>
Subject AW: [VOTE] Release on monday
Date Wed, 19 May 2004 14:24:28 GMT
just as a sidenote; I think the naming is somewhat wrong, it muddies the
contracts.

IMO there should be:
 - ObjectCache
	- responsibility: (temporarily) cache objects to increase performance
	- MIGHT persist these objects (if possible), but this is not guaranteed by
the contract
	- so, if objects implement Serializable (or otherwise qualify for being
persisted?) they MIGHT be persisted, but this is an implementation detail

 - ObjectStore
	- responsibility: persist/store objects non-temporarily
	- objects have to implement Serializable (or otherwise qualify for being
persisted?)

I don't see the need for the Store role. if my component needs objects
persisted I'll use ObjectStore, if I just need a cache for performance I'll
use ObjectCache. anything else should be configuration. e.g. xslt
transformer or the like; it wouldn't require a store. if I wanted it to use
a persisting cache I should be able to configure that.

the bottom line is that there are two contracts: cache and store. the Store
role as it currently exists is IMO unnecessary.


KISS ;-)

> -----Urspr√ľngliche Nachricht-----
> Von: dev-return-61136-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-61136-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Vadim Gritsenko
> Gesendet: Mittwoch, 19. Mai 2004 14:53
> An: dev@cocoon.apache.org
> Betreff: Re: [VOTE] Release on monday
>
>
> Sylvain Wallez wrote:
>
> > Joerg Heinicke wrote:
> >
> >> On 19.05.2004 13:02, Carsten Ziegeler wrote:
> >
> ...
>
> >>> - If you put objects into the store, they have to be serializable now.
> >>>   Even if JCS holds the data just in memory, it assumes that the
> >>>   objects are serializable. Perhaps they will change this perhaps
> >>>   not.
> >>
> >>
> >>
> >> What about the non-Serializable objects? Logicsheets and Paginator
> >> stuff were mentioned. Are these objects not put into transient store?
> >
> >
> >
> > Yep. And the transient store does not (and should not) require objects
> > to be serializable (that's its main purpose compared to the regular
> > store that may persist objects).
>
>
> Let's clarify something here about all those stores:
>
>     Transient store: MUST hold NON Serializable objects, MUST NOT
> persist objects.
>     Persistent store: MUST reject NON Serializable objects, MUST persist
> objects.
>     Store: MUST hold NON Serializable objects, CAN persist Serializable
> objects on overflow (or any other reason), MUST persist all Serializable
> objects on shutdown.
>
> For those who have not followed - this was the behavior of the stores in
> previous releases of Cocoon (before refactoring we had only two stores,
> IIRC, but same behavior). Given terminology above, we can have a working
> persistent store (JCS based), and working transient store (from
> Excalibur). General store is currently broken in two ways:
>   * It does not stores non serializable objects, but should.
>   * It does not persists cache on shutdown.
>
> I'm +1 on release, if and only if, we note these above bugs in the known
> issues list.
>
> Vadim
>


Mime
View raw message