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