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
