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
