Menu
▾
▴
naviserver-devel
|
From: Zoran V. <zv...@AR...> - 2005-12-29 19:37:21
|
Hi!
I believe you guys are more familiar with this stuff
as I am. Can you please comment?
Gustaf Neumann (XOTcl) is trying to get OACS to work
with our code and has some remarks. I'm forwarding the
relevant portion of an email sent to me today.
> i made some changes to oacs such it works with naviserver. The biggest
> problem was the changed argument passing conventions for filters. i am
> not sure, that the agument passing conventions of naviserver are
> the best
> possible choice, since
>
> ns_register_filter trace GET * myfilter
>
> calls now "myfilter {} WHY"
> instead of "myfilter WHY" as it was before. It should not be
> necessary to pass a nonexisting argument around. I would finde
> it more logically to have this as
> "myfilter WHY"
> or, when arguments are passed as
> "myfilter WHY arg1 arg2 ...."
>
> Since on has to alter the filter procs anyhow when moving from
> aolserver,
> this would not have beed a bad choice. With xotcl, i use e.g.
> an object handling the filter requests, such as
> Object create filter
> filter proc preauth ....
> filter proc postauth ...
> filter proc trace ....
>
> this worked nicely with the aolserver argument passing. now i have
> to use
> the strange looking method, that removes the empty first arg...
>
> filter proc {} args {my eval $args}
>
> Did you have some discussions about this? Is it to late to change
> this?
>
> In order to use oacs with naviserver, i had to introduce the following
> not very beautifiul mapping rules to keep the changes minimal and
> keep the server working for aolserver and naviserver.
>
> all the best
> -gustaf
>
>
> if {[ns_info name] eq "NaviServer"} {
> foreach filter {rp_filter rp_resources_filter
> request_denied_filter} {
> rename $filter ${filter}_aolserver
> proc $filter {_ why} [list ${filter}_aolserver \$why]
> }
>
> rename rp_invoke_filter rp_invoke_filter_conn
> proc rp_invoke_filter { filter_info why }
> { rp_invoke_filter_conn {} $filter_info $why }
> rename rp_invoke_proc rp_invoke_proc_conn
> proc rp_invoke_proc { argv } { rp_invoke_proc_conn
> {} $argv }
>
> rename rp_handler rp_handler_aolserver
> proc rp_handler {_} {rp_handler_aolserver}
> }
>
>
>
|
|
From: Zoran V. <zv...@ar...> - 2005-12-29 19:59:13
|
Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>>> ns_register_filter trace GET * myfilter
>>>
>>> calls now "myfilter {} WHY"
But *why* is this so? IOW, what is this empty argument
passed to the myfilter? Is this something we overlooked
or is it something done on purpose, or what?
I mean, maybe somebody has the answer out of the sleeve
and if not, I will have to dig into that...
Cheers
Zoran
|
|
From: Vlad S. <vl...@cr...> - 2005-12-29 20:07:07
|
It is in
int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
why arg is added after script args
We can change it easily to always specify why first
Zoran Vasiljevic wrote:
>
> Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>
>>>> ns_register_filter trace GET * myfilter
>>>>
>>>> calls now "myfilter {} WHY"
>
>
> But *why* is this so? IOW, what is this empty argument
> passed to the myfilter? Is this something we overlooked
> or is it something done on purpose, or what?
>
> I mean, maybe somebody has the answer out of the sleeve
> and if not, I will have to dig into that...
>
> Cheers
> Zoran
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Stephen D. <sd...@gm...> - 2005-12-29 21:04:11
|
Fixed in CVS a couple of days ago. My fault, I missread the original
code and thought that like registered procs, if you didn't explicitly
pass an arg a blank string was passed. Should work now.
On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> It is in
>
> int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>
> why arg is added after script args
>
> We can change it easily to always specify why first
>
>
> Zoran Vasiljevic wrote:
> >
> > Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
> >
> >>>> ns_register_filter trace GET * myfilter
> >>>>
> >>>> calls now "myfilter {} WHY"
> >
> >
> > But *why* is this so? IOW, what is this empty argument
> > passed to the myfilter? Is this something we overlooked
> > or is it something done on purpose, or what?
> >
> > I mean, maybe somebody has the answer out of the sleeve
> > and if not, I will have to dig into that...
> >
> > Cheers
> > Zoran
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > naviserver-devel mailing list
> > nav...@li...
> > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >
>
> --
> Vlad Seryakov
> 571 262-8608 office
> vl...@cr...
> http://www.crystalballinc.com/vlad/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Vlad S. <vl...@cr...> - 2005-12-29 21:17:50
|
It still has this comment, so we can get rid of that comment and fix the
order at the same time:-))
/*
* This really should be: cmd why ?arg?, but why and arg
* are reversed for backwards compatibility.
*/
Stephen Deasey wrote:
> Fixed in CVS a couple of days ago. My fault, I missread the original
> code and thought that like registered procs, if you didn't explicitly
> pass an arg a blank string was passed. Should work now.
>
>
>
>
> On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>
>>It is in
>>
>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>>
>>why arg is added after script args
>>
>>We can change it easily to always specify why first
>>
>>
>>Zoran Vasiljevic wrote:
>>
>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>>>
>>>
>>>>>> ns_register_filter trace GET * myfilter
>>>>>>
>>>>>>calls now "myfilter {} WHY"
>>>
>>>
>>>But *why* is this so? IOW, what is this empty argument
>>>passed to the myfilter? Is this something we overlooked
>>>or is it something done on purpose, or what?
>>>
>>>I mean, maybe somebody has the answer out of the sleeve
>>>and if not, I will have to dig into that...
>>>
>>>Cheers
>>>Zoran
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>files
>>>for problems? Stop! Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>_______________________________________________
>>>naviserver-devel mailing list
>>>nav...@li...
>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>
>>
>>--
>>Vlad Seryakov
>>571 262-8608 office
>>vl...@cr...
>>http://www.crystalballinc.com/vlad/
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems? Stop! Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>naviserver-devel mailing list
>>nav...@li...
>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Stephen D. <sd...@gm...> - 2005-12-30 01:40:36
|
I added the comment because the argument order is confusing. We could
change the order, but it not be compatible with AOLserver. Do large
bodies of code such as OpenACS use filter args? I think they do...
Something we could change is registered procs. Currently, an extra
args is always passed to the registered proc (a blank string if you
don't specify anything else). Dropping this would be cleaner. This
is an incompatible change, but it's easy to write code that works on
both AOLserver and NaviServer using defaults:
proc my_registered_proc {{context default}} { ... }
ns_register_proc GET /* my_registered_proc
ns_register_proc GET /* my_registered_proc my_context
What do you think?
On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> It still has this comment, so we can get rid of that comment and fix the
> order at the same time:-))
>
> /*
> * This really should be: cmd why ?arg?, but why and arg
> * are reversed for backwards compatibility.
> */
>
>
> Stephen Deasey wrote:
> > Fixed in CVS a couple of days ago. My fault, I missread the original
> > code and thought that like registered procs, if you didn't explicitly
> > pass an arg a blank string was passed. Should work now.
> >
> >
> >
> >
> > On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> >
> >>It is in
> >>
> >>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
> >>
> >>why arg is added after script args
> >>
> >>We can change it easily to always specify why first
> >>
> >>
> >>Zoran Vasiljevic wrote:
> >>
> >>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
> >>>
> >>>
> >>>>>> ns_register_filter trace GET * myfilter
> >>>>>>
> >>>>>>calls now "myfilter {} WHY"
> >>>
> >>>
> >>>But *why* is this so? IOW, what is this empty argument
> >>>passed to the myfilter? Is this something we overlooked
> >>>or is it something done on purpose, or what?
> >>>
> >>>I mean, maybe somebody has the answer out of the sleeve
> >>>and if not, I will have to dig into that...
> >>>
> >>>Cheers
> >>>Zoran
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> >>>files
> >>>for problems? Stop! Download the new AJAX search engine that makes
> >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK=
!
> >>>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>>_______________________________________________
> >>>naviserver-devel mailing list
> >>>nav...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>>
> >>
> >>--
> >>Vlad Seryakov
> >>571 262-8608 office
> >>vl...@cr...
> >>http://www.crystalballinc.com/vlad/
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> >>for problems? Stop! Download the new AJAX search engine that makes
> >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> >>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>_______________________________________________
> >>naviserver-devel mailing list
> >>nav...@li...
> >>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> > _______________________________________________
> > naviserver-devel mailing list
> > nav...@li...
> > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >
>
> --
> Vlad Seryakov
> 571 262-8608 office
> vl...@cr...
> http://www.crystalballinc.com/vlad/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Vlad S. <vl...@cr...> - 2005-12-30 02:04:15
|
Between three of us do we have a lot of code that uses filter with
aolserver's style of argument ordering?
If none, then i do not see why we cannot change it. Compatibility with
weird aolserver things never been our primary goal:-))
At least it will be one less confusing places in the code and API.
Stephen Deasey wrote:
> I added the comment because the argument order is confusing. We could
> change the order, but it not be compatible with AOLserver. Do large
> bodies of code such as OpenACS use filter args? I think they do...
>
>
> Something we could change is registered procs. Currently, an extra
> args is always passed to the registered proc (a blank string if you
> don't specify anything else). Dropping this would be cleaner. This
> is an incompatible change, but it's easy to write code that works on
> both AOLserver and NaviServer using defaults:
>
> proc my_registered_proc {{context default}} { ... }
> ns_register_proc GET /* my_registered_proc
> ns_register_proc GET /* my_registered_proc my_context
>
> What do you think?
>
>
> On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>
>>It still has this comment, so we can get rid of that comment and fix the
>>order at the same time:-))
>>
>>/*
>> * This really should be: cmd why ?arg?, but why and arg
>> * are reversed for backwards compatibility.
>> */
>>
>>
>>Stephen Deasey wrote:
>>
>>>Fixed in CVS a couple of days ago. My fault, I missread the original
>>>code and thought that like registered procs, if you didn't explicitly
>>>pass an arg a blank string was passed. Should work now.
>>>
>>>
>>>
>>>
>>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>>>
>>>
>>>>It is in
>>>>
>>>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>>>>
>>>>why arg is added after script args
>>>>
>>>>We can change it easily to always specify why first
>>>>
>>>>
>>>>Zoran Vasiljevic wrote:
>>>>
>>>>
>>>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>>>>>
>>>>>
>>>>>
>>>>>>>>ns_register_filter trace GET * myfilter
>>>>>>>>
>>>>>>>>calls now "myfilter {} WHY"
>>>>>
>>>>>
>>>>>But *why* is this so? IOW, what is this empty argument
>>>>>passed to the myfilter? Is this something we overlooked
>>>>>or is it something done on purpose, or what?
>>>>>
>>>>>I mean, maybe somebody has the answer out of the sleeve
>>>>>and if not, I will have to dig into that...
>>>>>
>>>>>Cheers
>>>>>Zoran
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>>>files
>>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>>_______________________________________________
>>>>>naviserver-devel mailing list
>>>>>nav...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>>
>>>>
>>>>--
>>>>Vlad Seryakov
>>>>571 262-8608 office
>>>>vl...@cr...
>>>>http://www.crystalballinc.com/vlad/
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>_______________________________________________
>>>>naviserver-devel mailing list
>>>>nav...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>for problems? Stop! Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>_______________________________________________
>>>naviserver-devel mailing list
>>>nav...@li...
>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>
>>
>>--
>>Vlad Seryakov
>>571 262-8608 office
>>vl...@cr...
>>http://www.crystalballinc.com/vlad/
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems? Stop! Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>naviserver-devel mailing list
>>nav...@li...
>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Stephen D. <sd...@gm...> - 2005-12-30 02:19:31
|
I'm all in favour of simplifying and clarifying, even when it means
some work is required on existing code. But in the case of filter
proc arg ordering there doesn't seem to be a clean way to write code
that will work on both AOLserver and NaviServer if the args are
reversed. Unless someone has any ideas..?
There are a few people now who've expressed interest in running
OpenACS on NaviServer and I wouldn't want to break things
gratuitously. The more people testing the code the better!
On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> Between three of us do we have a lot of code that uses filter with
> aolserver's style of argument ordering?
> If none, then i do not see why we cannot change it. Compatibility with
> weird aolserver things never been our primary goal:-))
>
> At least it will be one less confusing places in the code and API.
>
> Stephen Deasey wrote:
> > I added the comment because the argument order is confusing. We could
> > change the order, but it not be compatible with AOLserver. Do large
> > bodies of code such as OpenACS use filter args? I think they do...
> >
> >
> > Something we could change is registered procs. Currently, an extra
> > args is always passed to the registered proc (a blank string if you
> > don't specify anything else). Dropping this would be cleaner. This
> > is an incompatible change, but it's easy to write code that works on
> > both AOLserver and NaviServer using defaults:
> >
> > proc my_registered_proc {{context default}} { ... }
> > ns_register_proc GET /* my_registered_proc
> > ns_register_proc GET /* my_registered_proc my_context
> >
> > What do you think?
> >
> >
> > On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> >
> >>It still has this comment, so we can get rid of that comment and fix th=
e
> >>order at the same time:-))
> >>
> >>/*
> >> * This really should be: cmd why ?arg?, but why and arg
> >> * are reversed for backwards compatibility.
> >> */
> >>
> >>
> >>Stephen Deasey wrote:
> >>
> >>>Fixed in CVS a couple of days ago. My fault, I missread the original
> >>>code and thought that like registered procs, if you didn't explicitly
> >>>pass an arg a blank string was passed. Should work now.
> >>>
> >>>
> >>>
> >>>
> >>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> >>>
> >>>
> >>>>It is in
> >>>>
> >>>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
> >>>>
> >>>>why arg is added after script args
> >>>>
> >>>>We can change it easily to always specify why first
> >>>>
> >>>>
> >>>>Zoran Vasiljevic wrote:
> >>>>
> >>>>
> >>>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>ns_register_filter trace GET * myfilter
> >>>>>>>>
> >>>>>>>>calls now "myfilter {} WHY"
> >>>>>
> >>>>>
> >>>>>But *why* is this so? IOW, what is this empty argument
> >>>>>passed to the myfilter? Is this something we overlooked
> >>>>>or is it something done on purpose, or what?
> >>>>>
> >>>>>I mean, maybe somebody has the answer out of the sleeve
> >>>>>and if not, I will have to dig into that...
> >>>>>
> >>>>>Cheers
> >>>>>Zoran
> >>>>>
> >>>>>
> >>>>>-------------------------------------------------------
> >>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through l=
og
> >>>>>files
> >>>>>for problems? Stop! Download the new AJAX search engine that makes
> >>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLU=
NK!
> >>>>>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>>>>_______________________________________________
> >>>>>naviserver-devel mailing list
> >>>>>nav...@li...
> >>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>>>>
> >>>>
> >>>>--
> >>>>Vlad Seryakov
> >>>>571 262-8608 office
> >>>>vl...@cr...
> >>>>http://www.crystalballinc.com/vlad/
> >>>>
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g files
> >>>>for problems? Stop! Download the new AJAX search engine that makes
> >>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUN=
K!
> >>>>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>>>_______________________________________________
> >>>>naviserver-devel mailing list
> >>>>nav...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>>>
> >>>
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log=
files
> >>>for problems? Stop! Download the new AJAX search engine that makes
> >>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK=
!
> >>>http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> >>>_______________________________________________
> >>>naviserver-devel mailing list
> >>>nav...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>>
> >>
> >>--
> >>Vlad Seryakov
> >>571 262-8608 office
> >>vl...@cr...
> >>http://www.crystalballinc.com/vlad/
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> >>for problems? Stop! Download the new AJAX search engine that makes
> >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> >>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>_______________________________________________
> >>naviserver-devel mailing list
> >>nav...@li...
> >>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> > _______________________________________________
> > naviserver-devel mailing list
> > nav...@li...
> > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >
>
> --
> Vlad Seryakov
> 571 262-8608 office
> vl...@cr...
> http://www.crystalballinc.com/vlad/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Vlad S. <vl...@cr...> - 2005-12-30 02:26:20
|
Yes, i forgot about aolserver's way and people using it. So, now with
your patch it works the same way as aolserver? Then keep it.
Stephen Deasey wrote:
> I'm all in favour of simplifying and clarifying, even when it means
> some work is required on existing code. But in the case of filter
> proc arg ordering there doesn't seem to be a clean way to write code
> that will work on both AOLserver and NaviServer if the args are
> reversed. Unless someone has any ideas..?
>
> There are a few people now who've expressed interest in running
> OpenACS on NaviServer and I wouldn't want to break things
> gratuitously. The more people testing the code the better!
>
>
>
> On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>
>>Between three of us do we have a lot of code that uses filter with
>>aolserver's style of argument ordering?
>>If none, then i do not see why we cannot change it. Compatibility with
>>weird aolserver things never been our primary goal:-))
>>
>>At least it will be one less confusing places in the code and API.
>>
>>Stephen Deasey wrote:
>>
>>>I added the comment because the argument order is confusing. We could
>>>change the order, but it not be compatible with AOLserver. Do large
>>>bodies of code such as OpenACS use filter args? I think they do...
>>>
>>>
>>>Something we could change is registered procs. Currently, an extra
>>>args is always passed to the registered proc (a blank string if you
>>>don't specify anything else). Dropping this would be cleaner. This
>>>is an incompatible change, but it's easy to write code that works on
>>>both AOLserver and NaviServer using defaults:
>>>
>>> proc my_registered_proc {{context default}} { ... }
>>> ns_register_proc GET /* my_registered_proc
>>> ns_register_proc GET /* my_registered_proc my_context
>>>
>>>What do you think?
>>>
>>>
>>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>>>
>>>
>>>>It still has this comment, so we can get rid of that comment and fix the
>>>>order at the same time:-))
>>>>
>>>>/*
>>>> * This really should be: cmd why ?arg?, but why and arg
>>>> * are reversed for backwards compatibility.
>>>> */
>>>>
>>>>
>>>>Stephen Deasey wrote:
>>>>
>>>>
>>>>>Fixed in CVS a couple of days ago. My fault, I missread the original
>>>>>code and thought that like registered procs, if you didn't explicitly
>>>>>pass an arg a blank string was passed. Should work now.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>It is in
>>>>>>
>>>>>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>>>>>>
>>>>>>why arg is added after script args
>>>>>>
>>>>>>We can change it easily to always specify why first
>>>>>>
>>>>>>
>>>>>>Zoran Vasiljevic wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>ns_register_filter trace GET * myfilter
>>>>>>>>>>
>>>>>>>>>>calls now "myfilter {} WHY"
>>>>>>>
>>>>>>>
>>>>>>>But *why* is this so? IOW, what is this empty argument
>>>>>>>passed to the myfilter? Is this something we overlooked
>>>>>>>or is it something done on purpose, or what?
>>>>>>>
>>>>>>>I mean, maybe somebody has the answer out of the sleeve
>>>>>>>and if not, I will have to dig into that...
>>>>>>>
>>>>>>>Cheers
>>>>>>>Zoran
>>>>>>>
>>>>>>>
>>>>>>>-------------------------------------------------------
>>>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>>>>>files
>>>>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>>>>_______________________________________________
>>>>>>>naviserver-devel mailing list
>>>>>>>nav...@li...
>>>>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>>>>
>>>>>>
>>>>>>--
>>>>>>Vlad Seryakov
>>>>>>571 262-8608 office
>>>>>>vl...@cr...
>>>>>>http://www.crystalballinc.com/vlad/
>>>>>>
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>>>_______________________________________________
>>>>>>naviserver-devel mailing list
>>>>>>nav...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>>>_______________________________________________
>>>>>naviserver-devel mailing list
>>>>>nav...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>>
>>>>
>>>>--
>>>>Vlad Seryakov
>>>>571 262-8608 office
>>>>vl...@cr...
>>>>http://www.crystalballinc.com/vlad/
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>_______________________________________________
>>>>naviserver-devel mailing list
>>>>nav...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>for problems? Stop! Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>_______________________________________________
>>>naviserver-devel mailing list
>>>nav...@li...
>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>
>>
>>--
>>Vlad Seryakov
>>571 262-8608 office
>>vl...@cr...
>>http://www.crystalballinc.com/vlad/
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems? Stop! Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>naviserver-devel mailing list
>>nav...@li...
>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Zoran V. <zv...@ar...> - 2005-12-30 08:36:33
|
Am 30.12.2005 um 03:28 schrieb Vlad Seryakov: > So, now with your patch it works the same way as aolserver? Then > keep it. We will have to maintain a path between compatibility and cleanness. Not for any price but at places where it seems oportune. I agree with Vlad. Zoran |
|
From: Stephen D. <sd...@gm...> - 2005-12-30 11:46:43
|
On 12/30/05, Zoran Vasiljevic <zv...@ar...> wrote: > > Am 30.12.2005 um 03:28 schrieb Vlad Seryakov: > > > So, now with your patch it works the same way as aolserver? Then > > keep it. > > We will have to maintain a path between compatibility and cleanness. > Not for any price but at places where it seems oportune. > I agree with Vlad. > > Zoran Oh. Looks like Gustav hacked around this already: http://cvs.openacs.org/cvs/openacs-4/packages/acs-tcl/tcl/request-processor= -procs.tcl?r1=3D1.82.2.2&r2=3D1.82.2.3&sortby=3Ddate&only_with_tag=3Doacs-5= -2 If that's OK, then we could after all swap the args for filter procs.=20 Old code wouldn't work though. What to do? Is there a simillar problem with scheduled procs? I haven't investigated. http://cvs.openacs.org/cvs/openacs-4/packages/acs-tcl/tcl/utilities-procs.t= cl?r1=3D1.83.2.4&r2=3D1.83.2.5&sortby=3Ddate&only_with_tag=3Doacs-5-2 If bugs are reported we can fix them :-) |
|
From: Zoran V. <zv...@ar...> - 2005-12-30 13:36:57
|
Am 30.12.2005 um 12:46 schrieb Stephen Deasey: > On 12/30/05, Zoran Vasiljevic <zv...@ar...> wrote: >> >> Am 30.12.2005 um 03:28 schrieb Vlad Seryakov: >> >>> So, now with your patch it works the same way as aolserver? Then >>> keep it. >> >> We will have to maintain a path between compatibility and cleanness. >> Not for any price but at places where it seems oportune. >> I agree with Vlad. >> >> Zoran > > > Oh. Looks like Gustav hacked around this already: > > http://cvs.openacs.org/cvs/openacs-4/packages/acs-tcl/tcl/request- > processor-procs.tcl? > r1=1.82.2.2&r2=1.82.2.3&sortby=date&only_with_tag=oacs-5-2 > > If that's OK, then we could after all swap the args for filter procs. > Old code wouldn't work though. What to do? I would not require people to use such hacks, if possible. But I've been looking in the AS code and saw that ugly GetNumArgs(Tcl_Interp *interp, Proc *procPtr) which was used to decide wether an arg is expected or not. Brrrr.... that is pretty ugly. Why would we need to process that optional argument in the first place? Lets make the ns_register_filter as: ns_register_filter when method urlPattern script The "script" should be completely specified, for example set arg "whatever thing" ns_register_filter preauth GET /junk [list myfilter $arg] During runtime we'd append the WHY so it will be called as myfilter "whatever thing" preauth Wouldn't that be better/cleaner altogether? This will not break any code using no optional args (we never used this arg thing) and would be much more logical to understand. Hm? Zoran |
|
From: Gustaf N. <ne...@wu...> - 2005-12-30 18:20:04
|
Zoran Vasiljevic wrote:
>
>>
>> Why would we need to process that optional argument in the first place?
>>
>> Lets make the ns_register_filter as:
>> ns_register_filter when method urlPattern script
>>
>> The "script" should be completely specified, for example
>>
>> set arg "whatever thing"
>> ns_register_filter preauth GET /junk [list myfilter $arg]
>>
>> During runtime we'd append the WHY so it will be called as
>>
>> myfilter "whatever thing" preauth
>>
>> Wouldn't that be better/cleaner altogether? This will not break
>> any code using no optional args (we never used this arg thing)
>> and would be much more logical to understand.
>>
>> Hm?
how will be the call, when
ns_register_filter preauth GET /junk myfilter
is registered? when
myfilter preauth
is called, this would be pretty much comaptible with the aolserver for
the simple cases.
this would as well work with xotcl methods in this case. however, this
would as well be
the case, when WHY is placed before the passed arguments.
the hyperflexible approach would be to use
ns_register_filter preauth GET /junk [list myfilter arg1] arg2 arg3
which calls
myfilter arg1 preauth arg1 arg2
which means, cmd as you suggested, appending optional arguments. this means
ns_register_filter preauth GET /junk myfilter arg2 arg3
will make perfectly nice xotcl argumnt lists. In the simple case, this
ist still
comaptible with aolserver, in the complex cases, one has to do rewrite
the code anyhow.
-gustaf
>>
>> Zoran
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>> log files
>> for problems? Stop! Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li...
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
|
|
From: Zoran V. <zv...@ar...> - 2005-12-30 18:31:46
|
Am 30.12.2005 um 19:19 schrieb Gustaf Neumann:
>
> how will be the call, when
>
> ns_register_filter preauth GET /junk myfilter
>
> is registered? when
>
> myfilter preauth
Like this.
>
> is called, this would be pretty much comaptible with the aolserver
> for the simple cases.
> this would as well work with xotcl methods in this case. however,
> this would as well be
> the case, when WHY is placed before the passed arguments.
>
> the hyperflexible approach would be to use
>
> ns_register_filter preauth GET /junk [list myfilter arg1] arg2 arg3
I do not understan why bother with all this arguments (arg2 arg3, etc)
when you can easily construct the script using the [list] command?
In most of the callbacks I use (or have made in our C-code) I revert
to a single callback script line which must be prepared by the caller,
then registered. The C-implementation would then ADD arguments to it.
>
> which means, cmd as you suggested, appending optional arguments.
> this means
>
> ns_register_filter preauth GET /junk myfilter arg2 arg3
Again, I'd revert to:
ns_register_filter preauth GET /junk myfilter
and if you need to pass arguments to "myfilter" just use
ns_register_filter preauth GET /junk [list myfilter $arg1 $arg2
$arg3]
Would this be less flexible? I think not.
Cheers
Zoran
|
|
From: Gustaf N. <ne...@wu...> - 2005-12-31 00:15:21
|
Zoran Vasiljevic wrote:
>
> Am 30.12.2005 um 19:19 schrieb Gustaf Neumann:
>
>>
>> how will be the call, when
>>
>> ns_register_filter preauth GET /junk myfilter
>>
>> is registered? when
>>
>> myfilter preauth
>
> Like this.
fine.
>
>>
>> is called, this would be pretty much comaptible with the aolserver
>> for the simple cases.
>> this would as well work with xotcl methods in this case. however,
>> this would as well be
>> the case, when WHY is placed before the passed arguments.
>>
>> the hyperflexible approach would be to use
>>
>> ns_register_filter preauth GET /junk [list myfilter arg1] arg2 arg3
>
> I do not understan why bother with all this arguments (arg2 arg3, etc)
> when you can easily construct the script using the [list] command?
...
> and if you need to pass arguments to "myfilter" just use
> ns_register_filter preauth GET /junk [list myfilter $arg1 $arg2 $arg3]
> Would this be less flexible? I think not.
Flexible, well... Here is a reason: look at the example from my first
mail. with xotcl
(or other oo approaches) it is the most straightforward to implement the
filters as methods.
Class Filter
Filter instproc preauth args { .... }
Filter instproc postauth args { .... }
Filter myfilter
In such cases it is most conveniant, when the WHY argument is first, without
loosing the ability to pass to the handlers. When appending always the WHY
at the end, the arguments become the "methods", unless one has a
zero-argument filter proc.
When one needs an additional argument, one has to change the way to map he
methods.
i would be as happy with
ns_register_filter preauth GET /junk [list myfilter $arg1 $arg2 $arg3]
calling
myfilter WHY arg1 arg2 arg3
Certainly, in pure tcl cases, it does not matter much, where the WHY is
placed.
When the WHY is always appended to the end - as you suggests - i envision
myself defining the filter like
ns_register_filter preauth GET /junk [list myfilter preauth $arg1
$arg2 $arg3]
ns_register_filter postauth GET /junk [list myfilter postauth $arg1
$arg2 $arg3]
and not much caring about the WHY argument. certainly doable, but
slightly strange.
as i said before, the most common case it that the filter cmd is used
without
arguments. for the other cases, there is always a way to hack around.
decide, whatever you prefer.
all the best
-gustaf
|
|
From: Zoran V. <zv...@ar...> - 2005-12-31 07:08:45
|
Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
>
> Class Filter
> Filter instproc preauth args { .... }
> Filter instproc postauth args { .... }
>
Damn, you are right. In which case we'd do:
ns_register_filter <reason> GET /junk myfilter myarg1 myarg2 ...
and it would call the filter as:
myfilter <reason> myarg2 myarg3
Understand. This would allow you to:
Class TheFilter
TheFilter proc preauth {arg1 arg2} {...}
TheFilter proc postauth {arg1 arg2 arg3} {...}
ns_register_filter preauth GET /junk TheFilter arg1 arg2
ns_register_filter postauth GET /junk TheFilter arg1 arg2 arg3
and we'd call
TheFilter preauth arg1 arg2
TheFilter postauth arg1 arg2 arg3
The proc way would be:
proc TheFilter {reason args} {...}
and it would naturally fit in, as with OO syntax.
Well, this certainly makes sense to me. This is clean and elegant.
Hm... this will however be an incompatible change to the way AOL
server is handling the task, but will be way more sexy.
This is what I mean (others can comment): I'd go after this change.
For the people not using any optional arguments, there would be no
compatibility issues. For those using the arguments, they'd have to
rewrite the code. But it is for the better, not worse.
Stephen, Vlad, what do you think? I have no problem with that
as we are not using any of the optional args in our code.
We might examine to modify ns_register_proc the same way.
Cheers,
Zoran
|
|
From: Stephen D. <sd...@gm...> - 2005-12-31 11:54:48
|
On 12/31/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
>
> >
> > Class Filter
> > Filter instproc preauth args { .... }
> > Filter instproc postauth args { .... }
> >
>
> Damn, you are right. In which case we'd do:
>
> ns_register_filter <reason> GET /junk myfilter myarg1 myarg2 ...
>
> and it would call the filter as:
>
> myfilter <reason> myarg2 myarg3
>
> Understand. This would allow you to:
>
> Class TheFilter
> TheFilter proc preauth {arg1 arg2} {...}
> TheFilter proc postauth {arg1 arg2 arg3} {...}
>
> ns_register_filter preauth GET /junk TheFilter arg1 arg2
> ns_register_filter postauth GET /junk TheFilter arg1 arg2 arg3
>
> and we'd call
>
> TheFilter preauth arg1 arg2
> TheFilter postauth arg1 arg2 arg3
>
> The proc way would be:
>
> proc TheFilter {reason args} {...}
>
> and it would naturally fit in, as with OO syntax.
>
> Well, this certainly makes sense to me. This is clean and elegant.
> Hm... this will however be an incompatible change to the way AOL
> server is handling the task, but will be way more sexy.
>
> This is what I mean (others can comment): I'd go after this change.
> For the people not using any optional arguments, there would be no
> compatibility issues. For those using the arguments, they'd have to
> rewrite the code. But it is for the better, not worse.
>
> Stephen, Vlad, what do you think? I have no problem with that
> as we are not using any of the optional args in our code.
> We might examine to modify ns_register_proc the same way.
The order:
TheFilter preauth arg1 arg2
makes the most sense to me. The <when> is not an optional arg, it's
always appended. Required args always come before optional args in
proc specs...
If we changed this, we should also change Ns_TclEvalCallback() in the
same way. A proc registered with ns_serverrootproc may have the host
appended as the last arg. It uses Ns_TclEvalCallback() directly.
ns_register_proc doesn't append information of it's own. But it does
insist on appending a blank arg if none were supplied during
registration. I'd like to remove that as it's easy to write code
which works with either case.
|
|
From: Zoran V. <zv...@ar...> - 2005-12-31 12:19:14
|
Am 31.12.2005 um 12:54 schrieb Stephen Deasey: > > The order: > > TheFilter preauth arg1 arg2 > > makes the most sense to me. The <when> is not an optional arg, it's > always appended. Required args always come before optional args in > proc specs... Allright. > > If we changed this, we should also change Ns_TclEvalCallback() in the > same way. A proc registered with ns_serverrootproc may have the host > appended as the last arg. It uses Ns_TclEvalCallback() directly. Yes. > > ns_register_proc doesn't append information of it's own. But it does > insist on appending a blank arg if none were supplied during > registration. I'd like to remove that as it's easy to write code > which works with either case. Yes. Zoran |
|
From: Vlad S. <vl...@cr...> - 2005-12-31 17:22:14
|
Agreed on that as well, let's do it
Stephen Deasey wrote:
> On 12/31/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
>>Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
>>
>>
>>> Class Filter
>>> Filter instproc preauth args { .... }
>>> Filter instproc postauth args { .... }
>>>
>>
>>Damn, you are right. In which case we'd do:
>>
>> ns_register_filter <reason> GET /junk myfilter myarg1 myarg2 ...
>>
>>and it would call the filter as:
>>
>> myfilter <reason> myarg2 myarg3
>>
>>Understand. This would allow you to:
>>
>>Class TheFilter
>>TheFilter proc preauth {arg1 arg2} {...}
>>TheFilter proc postauth {arg1 arg2 arg3} {...}
>>
>>ns_register_filter preauth GET /junk TheFilter arg1 arg2
>>ns_register_filter postauth GET /junk TheFilter arg1 arg2 arg3
>>
>>and we'd call
>>
>>TheFilter preauth arg1 arg2
>>TheFilter postauth arg1 arg2 arg3
>>
>>The proc way would be:
>>
>>proc TheFilter {reason args} {...}
>>
>>and it would naturally fit in, as with OO syntax.
>>
>>Well, this certainly makes sense to me. This is clean and elegant.
>>Hm... this will however be an incompatible change to the way AOL
>>server is handling the task, but will be way more sexy.
>>
>>This is what I mean (others can comment): I'd go after this change.
>>For the people not using any optional arguments, there would be no
>>compatibility issues. For those using the arguments, they'd have to
>>rewrite the code. But it is for the better, not worse.
>>
>>Stephen, Vlad, what do you think? I have no problem with that
>>as we are not using any of the optional args in our code.
>>We might examine to modify ns_register_proc the same way.
>
>
>
> The order:
>
> TheFilter preauth arg1 arg2
>
> makes the most sense to me. The <when> is not an optional arg, it's
> always appended. Required args always come before optional args in
> proc specs...
>
> If we changed this, we should also change Ns_TclEvalCallback() in the
> same way. A proc registered with ns_serverrootproc may have the host
> appended as the last arg. It uses Ns_TclEvalCallback() directly.
>
> ns_register_proc doesn't append information of it's own. But it does
> insist on appending a blank arg if none were supplied during
> registration. I'd like to remove that as it's easy to write code
> which works with either case.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Zoran V. <zv...@ar...> - 2006-01-02 12:29:27
|
Am 31.12.2005 um 18:24 schrieb Vlad Seryakov:
> Agreed on that as well, let's do it
Conclusion:
ns_register_filter when method urlPattern script ?arg1 arg2 ...?"
The script definition must thus match:
proc script {when args} {...}
For calls w/o args, we are compatbile with AS.
For calls w/ args, we are not.
Who will do that? Stephen?
Cheers,
Zoran
|
|
From: Zoran V. <zv...@ar...> - 2006-01-11 18:04:27
|
Am 02.01.2006 um 13:31 schrieb Zoran Vasiljevic:
>
> Am 31.12.2005 um 18:24 schrieb Vlad Seryakov:
>
>> Agreed on that as well, let's do it
>
> Conclusion:
>
> ns_register_filter when method urlPattern script ?arg1 arg2 ...?"
>
> The script definition must thus match:
>
> proc script {when args} {...}
>
> For calls w/o args, we are compatbile with AS.
> For calls w/ args, we are not.
>
> Who will do that? Stephen?
I'm looking into this now... I will suggest we change
this for *all* Tcl callbacks. Therefore the:
Ns_TclCallback *
Ns_TclNewCallback(Tcl_Interp *interp, void *cbProc,
char *script, char *scriptarg)
should migrate to:
Ns_TclCallback *
Ns_TclNewCallback(Tcl_Interp *interp, void *cbProc,
char *script, int argc, char **argv)
where argc will hold the number and argv strings of all
arguments.
I do not know if anybody from outside is using this call
in which case we should name it something like:
Ns_TclNewCallbackEx
(admitently, not very innovative...)
Does anybody use this call? Vlad, do you use it in
some of your numerous modules?
Cheers
Zoran
|
|
From: Vlad S. <vl...@cr...> - 2006-01-11 19:57:23
|
No
Zoran Vasiljevic wrote:
>
> Am 02.01.2006 um 13:31 schrieb Zoran Vasiljevic:
>
>>
>> Am 31.12.2005 um 18:24 schrieb Vlad Seryakov:
>>
>>> Agreed on that as well, let's do it
>>
>>
>> Conclusion:
>>
>> ns_register_filter when method urlPattern script ?arg1 arg2 ...?"
>>
>> The script definition must thus match:
>>
>> proc script {when args} {...}
>>
>> For calls w/o args, we are compatbile with AS.
>> For calls w/ args, we are not.
>>
>> Who will do that? Stephen?
>
>
> I'm looking into this now... I will suggest we change
> this for *all* Tcl callbacks. Therefore the:
>
> Ns_TclCallback *
> Ns_TclNewCallback(Tcl_Interp *interp, void *cbProc,
> char *script, char *scriptarg)
>
> should migrate to:
>
> Ns_TclCallback *
> Ns_TclNewCallback(Tcl_Interp *interp, void *cbProc,
> char *script, int argc, char **argv)
>
> where argc will hold the number and argv strings of all
> arguments.
> I do not know if anybody from outside is using this call
> in which case we should name it something like:
>
> Ns_TclNewCallbackEx
>
> (admitently, not very innovative...)
>
> Does anybody use this call? Vlad, do you use it in
> some of your numerous modules?
>
> Cheers
> Zoran
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Zoran V. <zv...@ar...> - 2006-01-13 15:34:26
|
Am 11.01.2006 um 19:06 schrieb Zoran Vasiljevic:
> I'm looking into this now... I will suggest we change
> this for *all* Tcl callbacks.
I'm about to checkin changes to various ns_schedule_* and ns_register_*
procs to allow variable number of arguments passed to scripts as
discussed here.
Here is the list of procedures affected:
lexxsrv:nscp 3> ns_register_proc
wrong # args: should be "ns_register_proc ?-noinherit? ?--? method
url script ?args?"
lexxsrv:nscp 6> ns_register_url2file
wrong # args: should be "ns_register_url2file ?-noinherit? ?--? url
script ?args?"
lexxsrv:nscp 7> ns_register_filter
wrong # args: should be "ns_register_filter ?-first? ?--? when method
urlPattern script ?args?"
lexxsrv:nscp 8> ns_register_trace
wrong # args: should be "ns_register_trace method urlPattern script ?
args?"
lexxsrv:nscp 12> ns_schedule_proc
wrong # args: should be "ns_schedule_proc ?-once? ?-thread? ?--?
interval script ?args?"
lexxsrv:nscp 13> ns_schedule_weekly
wrong # args: should be "ns_schedule_weekly ?-once? ?-thread? ?--?
day hour minute script ?args?"
lexxsrv:nscp 14> ns_schedule_daily
wrong # args: should be "ns_schedule_daily ?-once? ?-thread? ?--?
hour minute script ?args?"
Normally, while building up the script, the optional args are always
appended
after the fixed arguments, in contrast to AS where, because of the
backward
compatibility reasons, some tricks are done with the command-line.
On the C-API....
The Ns_TclNewCallback is now:
NS_EXTERN Ns_TclCallback *Ns_TclNewCallback(Tcl_Interp *interp, void
*cbProc,
Tcl_Obj *scriptObjPtr,
int objc,
Tcl_Obj *CONST objv[]);
... so there is only object-based interface and it us used
from all over the code. The string-based interface equivalent
to the above is NOT implemented.
The Ns_TclNewCallbackObj is gone.
Please report any problems you find asap so I can fix them.
Oh yes: this is INCOMPATIBLE change, meaning scripts written
for AOLserver MAY NOT work correctly, but this is the price
to pay for a cleaner and more logical API.
Cheers
Zoran
|
|
From: Vlad S. <vl...@cr...> - 2005-12-29 19:53:17
|
In all my code i never used args in the filters, i always define filter
as proc filter { args} so for me it does not matter the order of the
arguments. Logically, WHY should be the first arg.
Zoran Vasiljevic wrote:
> Hi!
>
> I believe you guys are more familiar with this stuff
> as I am. Can you please comment?
>
> Gustaf Neumann (XOTcl) is trying to get OACS to work
> with our code and has some remarks. I'm forwarding the
> relevant portion of an email sent to me today.
>
>
>> i made some changes to oacs such it works with naviserver. The biggest
>> problem was the changed argument passing conventions for filters. i am
>> not sure, that the agument passing conventions of naviserver are the
>> best
>> possible choice, since
>>
>> ns_register_filter trace GET * myfilter
>>
>> calls now "myfilter {} WHY"
>> instead of "myfilter WHY" as it was before. It should not be
>> necessary to pass a nonexisting argument around. I would finde
>> it more logically to have this as
>> "myfilter WHY"
>> or, when arguments are passed as
>> "myfilter WHY arg1 arg2 ...."
>>
>> Since on has to alter the filter procs anyhow when moving from
>> aolserver,
>> this would not have beed a bad choice. With xotcl, i use e.g.
>> an object handling the filter requests, such as
>> Object create filter
>> filter proc preauth ....
>> filter proc postauth ...
>> filter proc trace ....
>>
>> this worked nicely with the aolserver argument passing. now i have to
>> use
>> the strange looking method, that removes the empty first arg...
>>
>> filter proc {} args {my eval $args}
>>
>> Did you have some discussions about this? Is it to late to change this?
>>
>> In order to use oacs with naviserver, i had to introduce the following
>> not very beautifiul mapping rules to keep the changes minimal and
>> keep the server working for aolserver and naviserver.
>>
>> all the best
>> -gustaf
>>
>>
>> if {[ns_info name] eq "NaviServer"} {
>> foreach filter {rp_filter rp_resources_filter request_denied_filter} {
>> rename $filter ${filter}_aolserver
>> proc $filter {_ why} [list ${filter}_aolserver \$why]
>> }
>>
>> rename rp_invoke_filter rp_invoke_filter_conn
>> proc rp_invoke_filter { filter_info why } { rp_invoke_filter_conn
>> {} $filter_info $why }
>> rename rp_invoke_proc rp_invoke_proc_conn
>> proc rp_invoke_proc { argv } { rp_invoke_proc_conn {}
>> $argv }
>>
>> rename rp_handler rp_handler_aolserver
>> proc rp_handler {_} {rp_handler_aolserver}
>> }
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X