[Zope-dev] Zope Head (2.8) breaks "refresh"

[Chris McDonough]

On Sat, 2003-12-13 at 22:10, Stuart Bishop wrote:
> Firstly, I've *never* had problems with refresh (as a user of) until
> Zope 2.7 (I only use it on my own products, so I must naturally code
> in a refresh friendly manner). I'm used to developing with autorefresh
> switched on for my products and it just *works*. If I make a change and
> don't see the expected behavior, I switch to the product refresh page to
> see where the syntax error is that caused the refresh to fail.

I must code in a particularly refresh-unfriendly manner because often
the globals I use in my code turn into Nones after a refresh, and it
leaves me in a place where I need to try to figure out whether it's my
problem or refresh's problem, and the first step in doing that is
restarting.  So I just cut out the middleman, because it's not much of a
bother.

I do agree that having autorefresh would be nice, though.  Debugging it
is just not problem I'm keen on tackling.  It's an amazing piece of work
by Shane, but it seems to have some limits that I don't quite
understand.  Either that or it works just fine but I just haven't used
it in a while.

> I've occasionally also used manual refresh to reload products on
> production servers without nuking sessions, but apart from that it is
> startup/teardown time. This is a problem though because doc/INSTALL.txt
> tells us to:
> 	./configure
> 	make instance
> 
> Until following the steps in doc/INSTALL.txt fires up a single ZEO
> server bound to the loopback address and a single ZEO client (with
> authentication on), the vast majority of developer and production
> installations will be ZEO-less. This also makes ZEO-less installations
> the best tested and most stable environment, or at least people will
> assume so.

Zope still starts in under a second with a very small index and in under
10 seconds with a large one (at least on my main development machines),
so even this isn't so terrible.  With the zopectl shell, it's even just
a matter of arrowing up in a terminal window and choosing "restart". 
But autorefresh would indeed kick the snot out of this any day if I felt
like I could rely on it unconditionally or if the conditions under which
it caused me problems were easily predictable.

- C