Frankly may be because i am doing hundreds things today i missed what needs to be changed. I am for changes:-))
ADP engine is what i've ported from AS 4.5. Stephen Deasey wrote: > 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 > ------------------------------------------------------------------------- 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
