Agreed. We’re probably not buying much in that C code except a lot more code 
for the same thing.

I’m like Massimo in that almost all of my recent projects have consisted of a 
single index.rvt in some directory along with a mod_rewrite call to that file 
to route the request. I didn’t use the various script declarations, I just put 
a call out in that file, but it’s the same idea. Mine looks something like this:

<? ss::page::route_request ?>

And then all the magic happens. :)


> On Sep 21, 2016, at 5:23 PM, Karl Lehenbauer <> wrote:
> 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" <> 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:
>> For additional commands, e-mail:
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
>  For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to