There's some new ADP result caching functionality. How does this
affect Tcl pages which are now executed by the ADP engine?
nsd/adpparse.c: NsAdpParse():
/*
* Special case when we evalutating Tcl file, we just wrap it as
* Tcl proc and save in ADP block with cache enabled or
* just execute the Tcl code in case of cache disabled
*/
nsd/adpeval.c: AdpSource():
/*
* Turn off TCL mode after cached result, in caching mode
* we wrap Tcl file into proc 'adp:filename' and return
* as result only
* ns_adp_append {<% adp:filename %>}
*
* The output will be cached as result and every time we call
* that Tcl file, cached command will be executed as long as
* file is unchanged, if modified then the file will be reloaded,
* recompiled into same Tcl proc and cached
*/
So when you enable result caching for ADP pages:
ns_section "ns/server/server1/adp"
ns_param cache true
or, in an adp page:
ns_adp_ctl cache true
or:
ns_adp_include -cache 1200 myfile.adp
what you're saying is after evaluating the script blocks in the adp,
and then combining them with the text blocks, cache that result and
don't re-execute the script blocks until the cache expires.
But for Tcl pages something different is going on. The exact same
config file option enables caching but now it means take the contents
of the Tcl file, make it the body of a hidden proc, then execute it
every time the page is called. The output is not cached.
In some respects this is fine. The commands that Tcl pages use:
ns_return, ns_write etc., aren't in any way hooked up to the guts of
the ADP code so it would require a some work to make response caching
work. Something for the future.
My questions are:
- does it make sense to do this extra step of turning the page into a
proc at all?
- does it make sense to overload the response caching config options for both?
(and have I read the code right?)
I guess my concern is that it's not obvious what's going on, both in
terms of configuration and code implementation, and that it's going to
hurt in the future when we want to add response caching to more parts
of the code.
I'm also wondering why two different strategies are being used for ADP
and Tcl pages which are essentially identical. The script blocks for
an ADP are cached per-interp which allows the byte-code to persist.
The Tcl pages are turned into procs (but only optionally).
ADP pages have a new 'singlescript' option which combines the text and
script blocks into a single script block. The intent was to allow code
to span <% .. %> boundaries, and a side effect is that a single error
aborts the whole page. But the interesting things is that now it's
basically a single chunk of Tcl to execute, like a Tcl page. Yet
they're handled differently...
Also, the constructed procs aren't garbage collected (same problem as
the old Tcl page code)...
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
