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

Reply via email to