Sylvain Wallez wrote:
Private caches all over the place
-
I mentioned above components that pre-analyze files like jxtemplate,
woody form definitions, flowscript, etc. Now if we look closer at
these components, we see that each of them has its own private cache
Sylvain Wallez wrote:
Christian Haul wrote:
This is a big problem, indeed. Since many of those actually build
their private cache from a source, I have started a SourceCache in the
scratchpad block but got distracted :-( Still, maybe it could be
useful when cleaning up the private caches.
The
Vadim Gritsenko wrote:
>
> Sylvain Wallez wrote:
> ...
>
> > I just wanted to clearly state the problems and proposed solutions so
> > that everybody understands and agrees with them or else yells ;-)
>
>
> All stuff sounds logical (with the exception of maxobjects=100 -- this
> is sample sitemap,
Christian Haul wrote:
Sylvain Wallez wrote:
- a transient store: in cocoon.xconf,
Store.TRANSIENT_STORE in Java code
- a persistent store: , Store.PERSISTANT_STORE
which equals Store.ROLE (more on this below)
The transient-store, as its name implies, should be transient, and
used to cache ob
Sylvain Wallez wrote:
- a transient store: in cocoon.xconf,
Store.TRANSIENT_STORE in Java code
- a persistent store: , Store.PERSISTANT_STORE which
equals Store.ROLE (more on this below)
The transient-store, as its name implies, should be transient, and used
to cache objects that should not be
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is a subject which is itching me badly: cocoon.xconf is way too big. We should remove every component definition that has the default built-in values (eventually leave them as comment) to simplify this frightening configuration file. The same
Sylvain Wallez wrote:
...
I just wanted to clearly state the problems and proposed solutions so
that everybody understands and agrees with them or else yells ;-)
All stuff sounds logical (with the exception of maxobjects=100 -- this
is sample sitemap, right? I do use higher number in production
Sylvain Wallez wrote:
>
> Mmmh... We currently have:
> String PERSISTENT_STORE = ROLE;
> wich should be:
> String PERSISTENT_STORE = ROLE + "/PersitentStore";
>
> A 20-character lazyness :-/
>
Yepp :( But don't forget the cocoon.xconf where you have to configure
a third store! So, you kno
Carsten Ziegeler wrote:
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
Geoff Howard wrote:
Overall agreement, just a few points to keep in mind below...
Sylvain Wallez wrote:
> Cocoon currently has two stores:
> - a transient store: in cocoon.xconf,
> Store.TRANSIENT_STORE in Java code
> - a persistent store: , Store.PERSISTANT_STORE which
> equals Store.ROLE (
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 h
Overall agreement, just a few points to keep in mind below...
Sylvain Wallez wrote:
> Geoff Howard wrote:
>
>> Bruno Dumon wrote:
>>
>>> On Wed, 2003-12-03 at 12:24, Joerg Heinicke wrote:
>>>
On 03.12.2003 10:01, Leszek Gawron wrote:
>>
>>
>>> There's also another problem: the store used
Big +1! This all seams to make much sense.
Sylvain Wallez wrote:
[Sylvain's exploit on stores snipped]
Joerg Heinicke wrote:
On 05.12.2003 23:38, Sylvain Wallez wrote:
Conclusion
--
The proposed changes want to clarify the respective roles of the
various stores, and make them behave as they should according to
their names (e.g. transient is really transient). This should allow
us to bet
Stefano Mazzocchi wrote:
God, yes, we need this a long time ago.
On 5 Dec 2003, at 14:38, Sylvain Wallez wrote:
[bunch of great stuff]
+1, but I can't help ATM.
No problem, the changes are rather small and I can do them (actually, it
may even be quicker than the analysis!)
I just wanted to
On 05.12.2003 23:38, Sylvain Wallez wrote:
Conclusion
--
The proposed changes want to clarify the respective roles of the various
stores, and make them behave as they should according to their names
(e.g. transient is really transient). This should allow us to better
understand what's g
God, yes, we need this a long time ago.
On 5 Dec 2003, at 14:38, Sylvain Wallez wrote:
[bunch of great stuff]
+1, but I can't help ATM.
--
Stefano.
smime.p7s
Description: S/MIME cryptographic signature
Sylvain Wallez wrote:
Note that it's very unlikely that some component other than
will directly use (direct read/write to disk without
a memory front-end isn't efficient). So we may want to write a new
class that combines MRU+Jisp to remove a from the
xconf file.
Oops, typo: you should
Geoff Howard wrote:
Bruno Dumon wrote:
On Wed, 2003-12-03 at 12:24, Joerg Heinicke wrote:
On 03.12.2003 10:01, Leszek Gawron wrote:
There's also another problem: the store used to cache the stylesheets
apparently tries to serialize the cached items to disk, as reported
here:
http://marc
19 matches
Mail list logo
