cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Added Resource Monitor in
Date Tue, 11 Dec 2001 17:06:23 GMT

Gerhard Froehlich a écrit :
> Sylvain,
> >From: Sylvain Wallez []
> >
> >
> >Gerhard Froehlich a écrit :
> >>
> >> Hi,
> >> I implemented the Excalibur Resource Monitor into
> >> The Resource Monitor observes now
> >> the cocoon.xconf file and notifies,
> >> when the file has changed.
> >>
> >> Cheers
> >> Gerhard
> >>
> >
> >Sorry to be so annoying about resource and monitors, but from a design
> >point of view, I think using ActiveMonitor this way is overkill.
> No problem, dude. False pride is unsuitable, searching for the
> most perfect solution is suitable!
> >As Berin said, the purpose of ActiveMonitor is to trigger some action
> >when a resource changes. Just changing the "lastModified" attribute
> >isn't IMO an action that justifies a background thread to periodically
> >monitor the filesystem.
> >
> >On the other hand, the FileResource with delayed call to
> >File.lastModified() I proposed yesterday (see
> > )
> >seems to me more appropriate in this case :
> >
> >- only Cocoon uses cocoon.xconf, and it already keeps the associated
> >Source object as an attribute. So there's no need to register it in a
> >centralized monitor.
> >
> >- like ActiveMonitor, it reduces the number of filesystem calls and
> >ensures the age of the "lastModified" information isn't greater that the
> >refresh period, but unlike ActiveMonitor, doesn't refresh it
> >unnecessarily at _every_ refresh period.
> >
> >Thoughts ?
> All your arguments above are correct. For the the ActiveMonitor is
> overkill, but what do you want? The was a starting point to implement
> a central Resource Monitoring to reduce our huge lastModified calls. Maybe
> is not right Example for lastModified calls. But look into
> the piplines (even CachingxxxPiplines).
> Somebody has to start, I did. Which way shall we take? Is this an
> issue or not?
> That's my question now!
> If not we can stop here now. If yes then we should search for a solution
> which fits.

Sorry if I offended you. I agree with your last sentence, but I was
afraid some important design decision would be taken too quickly just
because some code is in. As I seem to be the only one to have a
different opinion on this subject, I wanted to say it loud, because you
are coding so fast :)

So let's discuss the two strategies (ActiveMonitor / delayed system
calls) and see what finally comes out. It would be good also if other
people come in this discussion.

> <flame_point>
>   Sometimes I've the feeling the devs here are so keen on
>   integrating fancy and sexy new stuff into Cocoon that they forget the basis!
> </flame_point>

No flame from me here. I've spent and still spend much time (more
commits soon) correcting some non-blocking bugs that are annoying me in
my daily work.

> If you want, I remove this stuff for now, but only for a clean reboot of this
> issue ;-).

Let's keep it for now, until we decide if this is the right way to go or
not. I will try to spend some time for show-casing the strategy I
proposed, so people can look at both.


> Cheers
> Gerhard

Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message