That may be not ideal but my goal was to use same engine (ADP) for 
caching and keep compatibility. Also, performance-wise this is faster 
than the old mechanism. Anyway, to cache Tcl files, only proc can give 
that ability without re-parsing.


Stephen Deasey wrote:
> 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
> 


-------------------------------------------------------------------------
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

Reply via email to