Don Baccus wrote:
On Jun 6, 2011, at 12:25 PM, Andrew Piskorski wrote:
In general, I don't think the ACS/OpenACS 4.x request processor
design was EVER carefully thought out with respect to all of
AOLserver's features and use cases.
Or, in this case, didn't understand the bug that the internal
redirects on various errors like 404 didn't run the filters. Of
course, in AOLserver 3.0 (underwhich the rp was first written)
perhaps AOLserver did ...
I actually checked this before my initial post. It's been this way as
far as SF CVS goes back. Which is why I'm trying to tread lightly and
not break something that relies on the current behavior.
I admit to being somewhat astonished by the lack of orthogonality
when I figured this out in the AOLserver code.
It wasn't documented, and actually, rather than being an example of
the rp's design not being carefully thought out in regard to
AOLserver's features, I'd say that the design exposed a bug.
Could be a bug or a deliberate design decision. I recall one of the
AOL devs (Jim and Dossy?) at one point say that the featureset was very
much driven by internal AOL demands.
Of course, that was then, this is now. AOL is no longer the driving
force, or I don't think any force. And my first impression is to call
this behavior a bug, because it makes one kind of request (internal
redirects) act differently than a normal request, with no way to change
that. Others may agree or disagree, which is that I'm trying to find
out. And once that's clear, what to do about it.
I think it should be fixed to treat all requests, internal and external,
the same; but to be compatible this behavior should be switchable and
off by default. I have a half-patch for this (it's not switchable yet)
that I can clean up and commit sometime soon, if no one objects.
The OpenACS rp_* Tcl code just grabs control from the AOLserver
mechanisms.
And this is just stupid. If the AOLserver paradigm is that people
shouldn't write filters, it should not provide the facility to write
filters.
I got the impression (based on my reading alone, not talking to anyone
about it) that the request processor was created largely to give more
control (especially at the tcl level) than aolserver's native procs and
filters allow. So for instance the order of execution of filters could
be controlled rather than being executed in a strictly fifo by
definition order. As with any implementation it was a choice; a
different person might have patched the core to allow better control of
filters, and another person might have felt that the existing builtins
were good enough and relied more on them. No matter, it's there now and
it works and no one is complaining about it.
-J
PS: I really wasn't trying to stir up any arguments, I just wanted to
contribute something.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[email protected]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
