On 6/29/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote: > 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:-))
I'm not suggesting making any incompatible changes :-) You're saying the Tcl page code uses the ADP engine, I'm saying it doesn't. One of us is confused, and it's quite possibly me because I find some of the ADP code tricky. I've tried to explain but I think I've basically said the same thing twice so I'm not sure that it's helping. Do you accept what I'm saying, or is there something I've muddled up? > 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 > ------------------------------------------------------------------------- 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
