I've been thinking lately of a rather radical revision of the Tcl code
execution as it's done currently in mod_rivet. I haven't checked the
feasibility of every detail but I don't see fundamental and forbidding
obstacles to the implementation of such scheme.
Let's imagine to have mod_rivet replace the current C language machinery
of script evaluation by simply Tcl_Evaluating this script
try {
<content-generation-script>
} trap {RIVET ABORTPAGE} {
<abort-script>
} trap {RIVET THREAD_EXIT} {
<sudden-exit-script>
} on error {::rivet::error_code ::rivet::error_options} {
<error-script>
} finally {
<after-every-script>
}
The script could be composed in memory from configuration information,
for example omitting the <abort-script> trap or the 'finally' branch if
such handlers have not been set up. Also the error-script handler
determination could be done during the configuration stage and the
branch would be always existing al least with the default handler
The content generation script should by default be made by the
concatenation of the sequence
::Rivet initialize_request
eval <before-script>
namespace eval ::request { <url-script> }
eval <after-script>
which reproduces the current execution sequence. The script referenced
in the URL could be stored in the module status and in case accessed by
introducing a new command, something like
eval [::rivet::url_script]
the command should in case fetch the script from the cache. So far I can
see only problems impacting the performance, as I expect the C language
machinery to be faster, but in this case not dramatically faster than
the 'try....finally' construct (after all most requests are successfully
processed without errors. At least we hope so). Of course there are
possible optimizations like chaining the before-url-after scripts in one
script requiring a single call to Tcl_EvalObjEx
Perhaps I've been influenced by years of mod_rewrite usage where the
local path is analyzed and the transformation output blended into the
list of argument-value pairs to become the final URL query arguments. I
ended up having virtual hosts running websites with a single empty root
index.rvt and every template is parsed from the main application script.
Furthermore the content generation script is shared between different
applications and by no means resides in any directory tree pointed by
DocumentRoot directives. The bottom line is that the segmentation in 3
scripts has no meaning to me (..and for what I need also the URL
referenced script has no interest. But that's my approach...).
My point is that we could take a further step ahead and make the default
request processing script shown above entirely replaceable by a user
defined script (either based on try...on error...finally... or on any
other solutions the user would deem fit for their applications). Some
optimization could be attained by introducing some mechanism for
building such script by inclusion of the code, not simply sourcing or
parsing other files. The script could be kept in a special cache
providing some methods for determining its depends on the files it was
built from, in case one of them is modified requiring the buffer to be
refreshed.
opinions and criticism are welcome (...well, actually the latter are
less welcome, but don't be afraid ;-))
regards
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
