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
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.
Sylvain.
> Cheers
> Gerhard
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
