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 {
  } trap {RIVET ABORTPAGE} {
  } trap {RIVET THREAD_EXIT} {
  } on error {::rivet::error_code ::rivet::error_options} {
  } finally {

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 ;-))


 -- Massimo

To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Reply via email to