I think this is a good idea.  All the C code this would replace probably 
provides very little in terms of performance.

On 9/21/16, 4:03 PM, "Massimo Manghi" <mxman...@apache.org> wrote:

    I will carry on my analysis on this proposal and I will try as much as 
    possible to isolate into a single file the code to be changed for having 
    a working version of the model (unless fundamental incompatibilities 
    emerge). If this is possible I will create a branch with it.
    
    I have to set it aside for a while now
    
      -- Massimo
    
    On 09/19/2016 03:09 PM, Massimo Manghi wrote:
    > 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
    >
    >
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
    For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
    
    


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