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. :)
D
> On Sep 21, 2016, at 5:23 PM, Karl Lehenbauer <k...@flightaware.com> 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" <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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
