cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <>
Subject RE: Added Resource Monitor in
Date Wed, 12 Dec 2001 00:00:42 GMT
>From: Sylvain Wallez []
>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

I'm not offended! A quote from the actual flame war against jon in the
jakarta-general list "if you can't take the heat, then get out of the kitchen."

>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 :)

Hehe nice said. Maybe it was a little bit hasty the whole think, but
we learnd much, eh?

>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.

Yeah would be great. Stefano hint, hint ;)

>> <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.

Yupp as you want. No problem for me to remove this bit of code...


Never share a foxhole with anyone
braver than you are.

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

View raw message