Hi, I'm working at a very low priority, but regularly nonetheless, on
the documentation of Rivet 3.0.
I'm writing a manual page about the new Tcl based request processing
procedure (::Rivet::request_handling) and I suddenly realized that we
maybe have gotten used perhaps too much to the scenario where the
programmer is at the same time the master of the machine where an
application is running on. I maintain that most of the cases fit
perfectly in it: after all going to any cloud and create in matter of
seconds an instance of a new virtual machine makes less likely to have
promiscuous environments where interpreters have to be shared among
different application. mod_rivet has never fit very well in that case
anyway because you either have separate virtual interpreters or you
cannot rule out that an application could be fiddling around tampering
with data in other namespaces. But leaving open the possibility to any
application code to redefine ::Rivet::request_handling seems to me a bit
too much.
So I would like to change it a bit and my idea is the the code in
::Rivet::request_handling be moved in a file
(rivet/request_handling.tcl) and by default this file is read at startup
and stuffed into a Tcl object to be executed at the global level,
(instead of executing a call to ::Rivet::request_handling).
A new configuration directive will be introduced
RivetServerConf RequestHandler <tcl-script-filename>
where it's only argument *is* the name of a file with the code of a new
handler. I would like this directive could go into virtual hosts
definitions to be evaluated when separate virtual interpreters are On
but I cannot understand how effectively one can be sure that the
SeparateVirtualInterps directive will be evaluated before any possible
RequestHandler conf line.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
