What are you suggesting? i am not defending what is currently implemented but my only concern is backward compatibility, i have too many applications running on naviserver and many companies depend on it:-))
Stephen Deasey wrote: > 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 > ------------------------------------------------------------------------- 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
