Sylvain, >From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > >Gerhard Froehlich a écrit : >> >> Sylvain, >> >From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] >> > >> > >> >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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
