On 6/29/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote: > That may be not ideal but my goal was to use same engine (ADP) for > caching and keep compatibility.
Right, but that's what I'm saying: it's not using the same engine because Tcl pages are handled in a completely different way, but that mechanism is wedged into the ADP engine. > Also, performance-wise this is faster than the old mechanism. I'm confused about which mechanisms are which. I can think of 3: - original mechanism: http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/file.tcl?hideattic=0&view=markup - new mechanism 1 (effectively): page.adp: <% # your whole tcl page goes here %> - new mechanism 2: take above page and make it a proc (sounds exactly like original mechanism actually) Which is better than which other? > Anyway, to cache Tcl files, only proc can give > that ability without re-parsing. Either I'm confused about what's going on or I disagree :-) We have to agree on caching *what*. The thing that's new to ADP is *response* caching -- there has always been page-content-off-the-disk caching and byte-code-that-corresponds-to-page-off-disk caching. That's 3 different things that are being cached. Now, by turning Tcl pages into procs that's just a different way of byte-code caching, which is already fully supported by the ADP engine. The first problem is that this is confusing because you throw the switch for *reponse* caching but what you actually get is a different method of byte-code caching. The second problem is that if turning the code into a proc is noticeably faster than evaluating a Tcl string object, then why is it only available for Tcl pages and not part of the ADP engine itself, as it equally applies to ADP scripts in 'singlescript' mode. And, why is it optional? Response caching changes the semantics of a page, you can't just enable it for everything. But byte-code caching is just a faster way of getting the same result. Why would you ever want to turn this off? > 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 > ------------------------------------------------------------------------- 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
