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
