Sure thing.
> On Nov 12, 2016, at 11:29 AM, Massimo Manghi <man...@biol.unipr.it> wrote:
>
> good, but since you are willing to lay your hands on this code,please hold on
> an hour or two: I'm going to remove much of the surplus code still around in
> mod_rivet_ng.
>
> There are still a few calls to Tcl_EvalObjEx for procedures already defined
> at Tcl level that can be safely called from ::Rivet::request_handling
>
> -- Massimo
>
> On 11/12/2016 06:20 PM, Damon Courtney wrote:
>> 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
