The codebase is huge -- 350+ modules, written in a mixture of procedural and OO styles, no separation of concerns (e.g. html and js mixed in with perl), no tests, etc. Rewriting it would be optimal but not practical for my current circumstances, which is why I would like to "sandbox" the old code somehow so I can use it without too much modification. | [reply] [Watch: Dir/Any] |
One possible way to sandbox the CGI code is to run it in it's own process or thread. Depending on that code's behavior, you might not have to destroy the thread/process after each request.
Another possibility is to let the webserver run it and have your Dancer app either send a redirect to the user's webbrowser, or send it's own HTTP request to the webserver. Obviously, if you go the redirect route, the CGI app wil have to be modified to include a redirect back to the Dancer app in it's response to the webbrowser's request.
| [reply] [Watch: Dir/Any] |
So just sandbox a bunch of old crap and hope it holds up, again, for another 10 years ... good luck with that.
| [reply] [Watch: Dir/Any] |
Thanks -- it's creating the sandbox to prevent namespace pollution, etc., that this question is about.
| [reply] [Watch: Dir/Any] |