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/11/12 11:42:38 UTC
::rivet::inspect and mod_rivet_ng
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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Massimo Manghi <ma...@unipr.it>.
There is some more we can do. The template parser needs to know whether
the template is 'top-level' or not. If it's a URL referenced template
(toplevel=true) encloses the parsed script in a namespace request { }
statement. With the new model we could put that namespace evaluation in
::Rivet::url_handler. This would make the coupling of the Rivet parser
with other components a bit more relaxed, which is good design practice.
That would make possible to remove the hard coded ::request namespace
creation and move it in either ::Rivet::url_handler or request_handling
(the former probably a better choice because that would make the
::request namespace an almost exclusive responsibility of that procedure)
The problem is that this wouldn't work with the traditional mod_rivet
core, but I think I could manage the situation, even if we decided to
maintain that code by moving that 'namespace request {}' out of the
rivet parser: top level templates are evaluated in a specific and point
like condition
-- Massimo
On 11/12/2016 07:23 PM, Damon Courtney wrote:
> The first thing I see is that we need to set some of the defaults. We
> have some duplicating going on that can be cleaned up.
>
> Examples:
>
> ErrorScript should default to ::Rivet::handle_error
>
> AfterEveryScript should default to ::Rivet::cleanup_request
>
> Rather than looking for those scripts and then using the ::Rivet
> defaults when we don\u2019t find out, we should just default those values
> in the module, and then we don\u2019t have to do any of that dance.
>
> The only breaking change is that ::Rivet::cleanup_request is
> currently called on every request even if AfterEverScript has been
> specified. This would call for only one, which breaks backward
> compatibility, but I don\u2019t think in a really significant way. Most
> everyone should be using AfterEveryScript instead of the older way of
> redefining procs anyway.
>
> It looks like we\u2019re going to call this Rivet 3.0, so now is the time
> to reevaluate some old decisions and make changes. I don\u2019t think this
> is a big one or that controversial. I could be shouted down if
> someone cared enough though. :)
>
> D
>
>
>> On Nov 12, 2016, at 11:52 AM, Massimo Manghi <ma...@biol.unipr.it>
>> wrote:
>>
>> now the code its ready. You need to recreate an init.tcl script by
>> running ./configure with the appropriate arguments. The key switch
>> is
>>
>> ./configure ... --with-rivet-core=mod_rivet_ng
>>
>> the Tcl stuff in init.tcl.in pertaining only mod_rivet_ng is
>> comprised between the lines
>>
>> ######## mod_rivet_ng specific ++++++++
>>
>> .....
>>
>> ######## mod_rivet_ng specific --------
>>
>> everything else is untouched therefore it should be compatible also
>> with the traditional default core module
>>
>> I'm looking forward to read you comments
>>
>> cheers
>>
>> -- Massimo
>>
>>
>>
>> On 11/12/2016 06:34 PM, Damon Courtney wrote:
>>> Sure thing.
>>>
>>>
--
--
Dipartimento di Neuroscienze
Unit� Biofisica e Fisica Sanitaria
via Volturno 39
43125 Parma
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Massimo Manghi <ma...@unipr.it>.
Hi Damon, hi everyone
There is a new commit coming along that could clash with the init.tcl.in
you have rewritten, so please do an svn update before you commit.
I've fixed the issues with the broken tests, mostly caused by an
interaction between the [try] construct in ::Rivet::request_handling and
the ::rivet::catch and ::rivet::try commands.
Another bug surfaced in [::rivet::inspect script] and has been fixed
(even though it's not returning anything when called from outside an
HTTP request processing, but that's the value returned also in 2.3 IIRC)
The last test to be fixed is in broken.tcl which constrains an error
message to have a specific form. The new error message generated by
::Rivet::error_handler and ::Rivet::handle_error looks to have quite a
similar structure but it's not the same when compared character by
character (-exact matching in the test). That's because we have a
different frames stack when a command fails which is built in
::Rivet::request_handling. This test would fail also if the programmer
overrides one of those error handlers or if the old mod_rivet core is
built. I'm thus considering to switch to a looser regexp matching on
that test
-- Massimo
On 11/12/2016 07:23 PM, Damon Courtney wrote:
> The first thing I see is that we need to set some of the defaults. We
> have some duplicating going on that can be cleaned up.
>
> Examples:
>
> ErrorScript should default to ::Rivet::handle_error
>
> AfterEveryScript should default to ::Rivet::cleanup_request
>
> Rather than looking for those scripts and then using the ::Rivet
> defaults when we don\u2019t find out, we should just default those values
> in the module, and then we don\u2019t have to do any of that dance.
>
> The only breaking change is that ::Rivet::cleanup_request is
> currently called on every request even if AfterEverScript has been
> specified. This would call for only one, which breaks backward
> compatibility, but I don\u2019t think in a really significant way. Most
> everyone should be using AfterEveryScript instead of the older way of
> redefining procs anyway.
>
> It looks like we\u2019re going to call this Rivet 3.0, so now is the time
> to reevaluate some old decisions and make changes. I don\u2019t think this
> is a big one or that controversial. I could be shouted down if
> someone cared enough though. :)
>
> D
>
>
>> On Nov 12, 2016, at 11:52 AM, Massimo Manghi <ma...@biol.unipr.it>
>> wrote:
>>
>> now the code its ready. You need to recreate an init.tcl script by
>> running ./configure with the appropriate arguments. The key switch
>> is
>>
>> ./configure ... --with-rivet-core=mod_rivet_ng
>>
>> the Tcl stuff in init.tcl.in pertaining only mod_rivet_ng is
>> comprised between the lines
>>
>> ######## mod_rivet_ng specific ++++++++
>>
>> .....
>>
>> ######## mod_rivet_ng specific --------
>>
>> everything else is untouched therefore it should be compatible also
>> with the traditional default core module
>>
>> I'm looking forward to read you comments
>>
>> cheers
>>
>> -- Massimo
>>
>>
>>
>> On 11/12/2016 06:34 PM, Damon Courtney wrote:
>>> Sure thing.
>>>
>>>
--
--
Dipartimento di Neuroscienze
Unit� Biofisica e Fisica Sanitaria
via Volturno 39
43125 Parma
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Massimo Manghi <mx...@apache.org>.
In order to reset your password apparently you need to just visit
https://id.apache.org/
the subversion repository password is the same password: they had been
unified years ago, therefore you should be OK following that procedure
what if we had the subversion repository mirrored on git?
-- Massimo
On 11/12/2016 09:10 PM, Damon Courtney wrote:
> Also, I have no idea what my SVN credentials are, so I can\u2019t commit
> anything. I don\u2019t particularly want to deal with the bureaucracy of
> all that, so can I just submit a patch?
>
> D
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Massimo Manghi <mx...@apache.org>.
Yes, sure but if having your credentials back could whet your appetite
for more commits and contributions I would gladly help
-- Massimo
On 11/12/2016 09:10 PM, Damon Courtney wrote:
> Also, I have no idea what my SVN credentials are, so I can\u2019t commit
> anything. I don\u2019t particularly want to deal with the bureaucracy of
> all that, so can I just submit a patch?
>
> D
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Damon Courtney <da...@tclhome.com>.
Also, I have no idea what my SVN credentials are, so I can’t commit anything. I don’t particularly want to deal with the bureaucracy of all that, so can I just submit a patch?
D
> On Nov 12, 2016, at 12:23 PM, Damon Courtney <da...@tclhome.com> wrote:
>
> The first thing I see is that we need to set some of the defaults. We have some duplicating going on that can be cleaned up.
>
> Examples:
>
> ErrorScript should default to ::Rivet::handle_error
>
> AfterEveryScript should default to ::Rivet::cleanup_request
>
> Rather than looking for those scripts and then using the ::Rivet defaults when we don’t find out, we should just default those values in the module, and then we don’t have to do any of that dance.
>
> The only breaking change is that ::Rivet::cleanup_request is currently called on every request even if AfterEverScript has been specified. This would call for only one, which breaks backward compatibility, but I don’t think in a really significant way. Most everyone should be using AfterEveryScript instead of the older way of redefining procs anyway.
>
> It looks like we’re going to call this Rivet 3.0, so now is the time to reevaluate some old decisions and make changes. I don’t think this is a big one or that controversial. I could be shouted down if someone cared enough though. :)
>
> D
>
>
>> On Nov 12, 2016, at 11:52 AM, Massimo Manghi <ma...@biol.unipr.it> wrote:
>>
>> now the code its ready. You need to recreate an init.tcl script by running ./configure with the appropriate arguments. The key switch is
>>
>> ./configure ... --with-rivet-core=mod_rivet_ng
>>
>> the Tcl stuff in init.tcl.in pertaining only mod_rivet_ng is comprised between the lines
>>
>> ######## mod_rivet_ng specific ++++++++
>>
>> .....
>>
>> ######## mod_rivet_ng specific --------
>>
>> everything else is untouched therefore it should be compatible also with the traditional default core module
>>
>> I'm looking forward to read you comments
>>
>> cheers
>>
>> -- Massimo
>>
>>
>>
>> On 11/12/2016 06:34 PM, Damon Courtney wrote:
>>> Sure thing.
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Damon Courtney <da...@tclhome.com>.
The first thing I see is that we need to set some of the defaults. We have some duplicating going on that can be cleaned up.
Examples:
ErrorScript should default to ::Rivet::handle_error
AfterEveryScript should default to ::Rivet::cleanup_request
Rather than looking for those scripts and then using the ::Rivet defaults when we don’t find out, we should just default those values in the module, and then we don’t have to do any of that dance.
The only breaking change is that ::Rivet::cleanup_request is currently called on every request even if AfterEverScript has been specified. This would call for only one, which breaks backward compatibility, but I don’t think in a really significant way. Most everyone should be using AfterEveryScript instead of the older way of redefining procs anyway.
It looks like we’re going to call this Rivet 3.0, so now is the time to reevaluate some old decisions and make changes. I don’t think this is a big one or that controversial. I could be shouted down if someone cared enough though. :)
D
> On Nov 12, 2016, at 11:52 AM, Massimo Manghi <ma...@biol.unipr.it> wrote:
>
> now the code its ready. You need to recreate an init.tcl script by running ./configure with the appropriate arguments. The key switch is
>
> ./configure ... --with-rivet-core=mod_rivet_ng
>
> the Tcl stuff in init.tcl.in pertaining only mod_rivet_ng is comprised between the lines
>
> ######## mod_rivet_ng specific ++++++++
>
> .....
>
> ######## mod_rivet_ng specific --------
>
> everything else is untouched therefore it should be compatible also with the traditional default core module
>
> I'm looking forward to read you comments
>
> cheers
>
> -- Massimo
>
>
>
> On 11/12/2016 06:34 PM, Damon Courtney wrote:
>> Sure thing.
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Massimo Manghi <ma...@biol.unipr.it>.
now the code its ready. You need to recreate an init.tcl script by
running ./configure with the appropriate arguments. The key switch is
./configure ... --with-rivet-core=mod_rivet_ng
the Tcl stuff in init.tcl.in pertaining only mod_rivet_ng is comprised
between the lines
######## mod_rivet_ng specific ++++++++
.....
######## mod_rivet_ng specific --------
everything else is untouched therefore it should be compatible also with
the traditional default core module
I'm looking forward to read you comments
cheers
-- Massimo
On 11/12/2016 06:34 PM, Damon Courtney wrote:
> Sure thing.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Damon Courtney <da...@tclhome.com>.
Sure thing.
> On Nov 12, 2016, at 11:29 AM, Massimo Manghi <ma...@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 <mx...@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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Massimo Manghi <ma...@biol.unipr.it>.
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\u2019t think is a breaking change. I don\u2019t imagine anyone is using
>> the \u201cundefined\u201d 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\u2019d like to see if I
>> can contribute to the efforts.
>>
>> Also, I\u2019ll 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 <mx...@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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Damon Courtney <da...@tclhome.com>.
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 <mx...@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-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: ::rivet::inspect and mod_rivet_ng
Posted by Massimo Manghi <ma...@biol.unipr.it>.
After this landslide support for changing the ::rivet::inspect behaviour
would you agree to change it also il branches/2.3?
-- Massimo
On 11/14/2016 10:41 AM, Ronnie Brunner wrote:
>> EVERYTHING is a string, Massimo!
>
> +1
>
>> 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.
>
> +1
>
> Gruess
> Ronnie
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Ronnie Brunner <ro...@netcetera.com>.
> EVERYTHING is a string, Massimo!
+1
> 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.
+1
Gruess
Ronnie
--
Ronnie Brunner | ronnie.brunner@netcetera.com | T +41 44 297 59 79 |
Netcetera AG | 8040 Zrich | Switzerland | http://netcetera.com |
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: ::rivet::inspect and mod_rivet_ng
Posted by Damon Courtney <da...@tclhome.com>.
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 <mx...@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-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