Ok, it's good that there are other devs reading, it means I can toss out
ideas and get useful feedback on them :)
Jim Davidson wrote:
Howdy,
I still watch the list but haven't had time to dig into the code in a
long time -- maybe later this summer :)
I unfortunately have more time to think
On Jun 6, 2011, at 11:31 AM, Jeff Rogers wrote:
I get down into these filters trying to figure out why my OpenACS
installation returned error pages for bad urls instead of the configured 404
page. What appears to be going on is that a preauth filter rp_filter is
set up to do
On Mon, Jun 06, 2011 at 11:31:02AM -0700, Jeff Rogers wrote:
This also makes it impossible to use acs-templating on the 404 or
500 error page.
As I vaguely recall from 10+ years ago, it can be done, although it's
not obvious. I did it by dynamically calling the underlying
acs-templating
Don Baccus wrote:
On Jun 6, 2011, at 11:31 AM, Jeff Rogers wrote:
I get down into these filters trying to figure out why my OpenACS
installation returned error pages for bad urls instead of the
Yes, this has been a known problem and known to be due to the fact
that filter's not being run.
On Jun 6, 2011, at 2:08 PM, Jeff Rogers wrote:
Well my question for now is, if this was fixed/changed in a way like I've
suggested, how long would it be before OpenACS could take advantage of the
change?
Wouldn't it just work automagically if the filter were run and context set up
Don Baccus wrote:
On Jun 6, 2011, at 2:08 PM, Jeff Rogers wrote:
Well my question for now is, if this was fixed/changed in a way
like I've suggested, how long would it be before OpenACS could take
advantage of the change?
Wouldn't it just work automagically if the filter were run and
context
On Jun 6, 2011, at 4:49 PM, Jeff Rogers wrote:
Of course, this is all theoretical right now. It would be a lot easier to
reason about it if there was a real use case.
Yes, it is.
There's very little development activity around OpenACS these days, and I can't
think of anything in
On Mon, Jun 06, 2011 at 05:31:44PM -0700, Don Baccus wrote:
(contrary to an opinion stated in a previous post, the request
processor implementation is efficient, and isn't an indication that
the implementer didn't understand AOLserver,
That isn't what I said, Don. There's nothing in
On Jun 6, 2011, at 6:07 PM, Andrew Piskorski wrote:
On Mon, Jun 06, 2011 at 05:31:44PM -0700, Don Baccus wrote:
(contrary to an opinion stated in a previous post, the request
processor implementation is efficient, and isn't an indication that
the implementer didn't understand AOLserver,
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
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
Hi Jeff,
I read the lists to remind myself of the joy of working with a nicely
threaded server and the awesome old-school OpenACS community. It's amazing
how many ex-OpenACSers I have the pleasure of being colleagues and friends
with in totally different areas of life :)
Now, if I ever get back
Howdy,
I still watch the list but haven't had time to dig into the code in a long time
-- maybe later this summer :)
Anyway, these connection filters are a bit confusing and not well documented --
my fault. Here I think it's ok to not call the filters again but it could go
either way. If
Yes, but things have been really low volume ... ;)
On 6/2/11 9:04 PM, Jeff Rogers wrote:
PS: are any other developers even still reading this?
--
Dossy Shiobara | He realized the fastest way to change
do...@panoptic.com | is to laugh at your own folly -- then you
14 matches
Mail list logo
