[Zope-Coders] CallProfiler and Refresh.

[Anthony Baxter]

>>> "Brian Lloyd" wrote
>   - It seems like the ability to turn profiling on and off should 
>     be protected by a more specific permission than "View management 
>     screens", considering that you can affect the overall performance 
>     of the site. What do you think of some sort of "Use call profiler" 
>     permission so that this is explicit?

I'm normally wary of adding Yet More Bloat to the security page, but 
this is probably worthwhile. Note that it's only really appropriate 
at the top level of the zodb.

>   - The add form for CallProfiler objects is nearly blank other 
>     than the id text box and an oddly-named "Submit Query" button. 
>     This should be fixed to be consistent with other managment 
>     "add" screens (some short verbage, help link, consistent look 
>     etc.)

Not quite sure why that's still there - it doesn't need to be.

>   - There's no help / docs that I could find other than the README
>     in the CallProfiler product directory. There needs to be at 

Yep. This is a known thing To Be Done.
> 
>   - The different views aren't too consistent style-wise. We should 
>     get them using the standard ZMI styles. That's a bit of arcana, 
>     I know, as it's underdocumented what "should" be done. I'd be 
>     happy to help out with that part if you'd like.

That would be good. note that some of the data CP's views present 
(large amounts of statistics) aren't really similar to much else in
the ZMI, and using only the standard ZMI presentation might lead to
difficulties in reading the screens.

>   - I'd _really_ like to find an answer to the refresh problem 
>     if possible wrt: publisher hooks. The idea that a refresh 
>     could hose the whole instance makes me feel oogy :) I can 
>     pitch in on this as well if it will help.

Yeah. I've tried a bunch of stuff, and short of making some of the
modules non-refreshable and moving the hook there, I couldn't see
a way to do it. Ideally, refresh would get a hook to call into the
about-to-be-refreshed product to say "hey, get ready for a refresh",
but that's still not a great approach.

> Overall though, it's getting close. I like the way you've 
> factored the monkey-patcher. I suspect that making that 
> approach work for the cache / publisher patching could 
> be a way to make refresh work without problems too.

The problem is that when the refresh happens, the module containing
the hook gets stomped. This means a whole pile of things "go away" -
certainly all the globals die. I tried making sure that all code in
the hooks used only locals, but that also didn't help (can't remember
exactly why right now)

Ok, so should I check it into the trunk so that people can be exposed 
to it and the help and UI can get more eyeballs? At the moment, simply
not having a refresh.txt is a simply enough "fix" to the refresh problem
until there's a solution.

Anthony
-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.