Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Gerhard Froehlich" <g-froehlich@gmx.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Added Resource Monitor in Cocoon.java
Date: Wed, 12 Dec 2001 01:00:42 +0100
Message-ID: <LDEKKGCNJLEPFDOEIHFDKEGACKAA.g-froehlich@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Importance: Normal
In-Reply-To: <3C163D0F.CCE4DAF3@anyware-tech.com>

Sylvain,
>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
>
>Gerhard Froehlich a �crit :
>>
>> Sylvain,
>> >From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>> >
>> >
>> >Gerhard Froehlich a �crit :
>> >>
>> >> Hi,
>> >> I implemented the Excalibur Resource Monitor into
>> >> Cocoon.java. The Resource Monitor observes now
>> >> the cocoon.xconf file and notifies Cocoon.java,
>> >> 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
>> >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100799905918225&w=2 )
>> >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 Cocoon.java the ActiveMonitor is
>> overkill, but what do you want? The Cocoon.java was a starting point to implement
>> a central Resource Monitoring to reduce our huge lastModified calls. Maybe
>> Cocoon.java 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...

Cheers
Gerhard


---------------------------------
Never share a foxhole with anyone
braver than you are.
---------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org