On Wed, 2003-07-02 at 20:38, Andrew Ho wrote: > I totally agree with the fact that Apache::Registry can introduce many > hard-to-debug-problems. I've had enough headaches debugging some of these > issues myself. It's unclear to me, though, that there are unimaginably > cool things you can get to in a "real" content handler that you can't get > to from an Apache::Registry script
I would phrase it differently and say that there are nice things you can do when you embrace the fact that you're in a persistent environment. You can do a lot of things in ways that are compatible with both CGI and mod_perl, by checking the environment and acting appropriately, but it can be a pain when you want to take advantage of cleanup handlers, preloaded data, persistent connections, etc. You can do all this from A::R, but once you've decided to write something that is not going to work under CGI I can't see any reason to use A::R anymore. At that point, it's just an artificial construct that adds complexity to your system. > I have found that often the Apache::Registry functionality of not having > to restart servers when simple scripts change is worth the potential of > bugs tickled by the Apache::Registry sub-wrap approach. People often say this. I just don't see it. Apache::Reload works just as well. My dev server restarts in about a second, so I always restart it when I make a change just to feel confident that I'm not seeing any residual effects from previous code. The whole reload thing is not perfect anyway, and people have had problems with A::R's reload when working with code that has closures in it. My opinion is that you should use A::R if you need CGI (or SpeedyCGI, etc.) compatibility, but use handlers otherwise. - Perrin
