Forum OpenACS Development: Summary of current request processor serving of /request/* files ...

This is what I've implemented thus far.  Thought I'd start a new thread so folks can comment directly on these changes ...

The code does this:

1. tries to map /resources/package-key/* to packages/package-key/www/resources/*

2. if 1 fails, tries to map /resources/* to www/resources/*

3. if 1 or 2 finds the file, we just ns_returnfile the file and do a return filter_return to stop further processing for this request

4. if not found it returns filter_ok, which causes the request to be processed normally.  I did this because legacy sites with a package mounted at /resources probably don't want to see that package suddenly break ... feedback?

5. Rather than make an acs-resources package that appears in the site map as /resources, I'm back to an earlier though that Jeff, Lars and I had agreed upon: make /resources an illegal mount name.  I actually don't like this much ... perhaps we should use /acs-resources rather than /resources, make the simple package I described earlier, and mount this package at /acs-resources at OpenACS create time and in upgrade scripts for 5.0.  Feedback appreciated here, too.

6. Currently a file that exists for a package that's not mounted gets returned.  This isn't necessarily the right thing to do.  We could easily modify the semantics of this thing to serve resource files normally unless performance mode is turned on.  If performance mode were on we could use the global url-to-file map to do the file mapping.  This map won't map packages that aren't mounted.  We'd have just about the same efficiency of execution.  Is it worth doing this?  After all we're talking about files which are safe to return in any case, scripts are never executed by this filter.  My thinking is the simple, fast approach is OK but thought I'd float the perhaps aesthetically cleaner notion of only serving resource files for mounted packages as an alternative ...

At the moment you can get the new request processor and a new copy of the dotlrn package on HEAD to see how the simple rp_resources_filter has been implemented and to look at a package that takes advantage of it.

Tomorrow is our 4th of July holiday so it will be a great opportunity for you non-yanks to dominate the discussion since many folks will be taking the day off!  Now's your chance!