You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <mx...@apache.org> on 2016/09/19 13:09:00 UTC
a new script execution model for mod_rivet
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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: a new script execution model for mod_rivet
Posted by Damon Courtney <da...@tclhome.com>.
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 <ka...@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" <mx...@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-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: a new script execution model for mod_rivet
Posted by Karl Lehenbauer <ka...@flightaware.com>.
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" <mx...@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-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: a new script execution model for mod_rivet
Posted by Massimo Manghi <mx...@apache.org>.
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-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org