Never mind. I found it.
D
> On Nov 12, 2016, at 9:57 AM, Damon Courtney <da...@tclhome.com> wrote:
>
> EVERYTHING is a string, Massimo!
>
> I don’t think is a breaking change. I don’t imagine anyone is using the
> “undefined” behavior, and an empty string is definitely the right answer for
> Tcl.
>
> Is there anywhere I can browse this code on the web? I think this will be a
> great change and simplification, and I’d like to see if I can contribute to
> the efforts.
>
> Also, I’ll be at the Tcl Conference next week if anyone on here wants to hang
> out. :)
>
> D
>
>
>> On Nov 12, 2016, at 5:42 AM, Massimo Manghi <mxman...@apache.org> wrote:
>>
>> Hi guys, I've been working on the new request processing model and I hit a
>> problem caused by a silly choice I did when I wrote the ::rivet::inspect
>> command.
>>
>> I've figured out that deep in my soul after all I'm a reluctant tcler: I
>> haven't accepted nor understood some of the EIAS paradigm consequences. For
>> example
>>
>> [::rivet::inspect BeforeScript] returns the script stored in
>>
>> (*(rivet_server_conf*) Rivet_GetConf(s))->rivet_before_script
>>
>> which can be NULL. It's customary to return an empty string at Tcl level but
>> in this case I though it could be meaningful to treat a NULL and a (utterly
>> unlikely) empty script differently and decided to return the "undefined"
>> string if the pointer was not set. Silly.
>>
>> The new central procedure for handling a request (::Rivet::request_handling)
>> has a call to this procedure at its heart
>>
>> proc url_handler {} {
>>
>> set script ""
>>
>> set before_script [::rivet::inspect BeforeScript]
>> if {$before_script == "undefined"} {
>> set before_script ""
>> }
>>
>> set script [::rivet::url_script]
>>
>> set after_script [::rivet::inspect AfterScript]
>> if {$after_script == "undefined"} {
>>
>> set after_script ""
>>
>> }
>>
>> set script [join [list $before_script $script $after_script] "\n"]
>> return $script
>> }
>>
>> this procedure is evaluated at every request and along with
>> ::Rivet::request_handling overrides a few hundreds lines of C language code.
>> I would like to see those useless if conditions go away and therefore I
>> would change the inspect command in trunk in order to have it return empty
>> strings when a pointer is NULL. I doubt that anyone around is depending on
>> those "undefined" string in their code so I'm pretty confident this is not
>> breaking a big deal of software
>>
>> The mod_rivet_ng code is reaching a decent degree of maturity: it's still
>> breaking a few tests but I can already run some of my applications on it.
>> The core of the Tcl code evaluation is the ::Rivet::request_handling (I
>> establish the ::Rivet namespace as the place for anything that should be
>> considered 'critical' and 'fundamental' to mod_rivet). This procedure
>> reproduces the basic scheme (by using a Tcl ::try construct)
>>
>> * <content-generation> (::Rivet::url_handler)
>> - <abort script execution>
>> - <error script>
>>
>> * <after every script>
>>
>> In principle you may override these procedure and further simplify (or
>> develop) the request processing following your needs. The current version in
>> the repository has a few debugging 'puts' around that have to be removed if
>> you want to try it yourself.
>>
>> saluti
>>
>> -- 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
