On 12/24/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Am 23.12.2005 um 20:03 schrieb Stephen Deasey: > > > Yes, good points. I've uploaded a new patch which merges everything > > into the core with minimal changes to existing C code. Let me know > > how this looks. > > Great! > > > > > Regarding API compatibility for Tcl code, I thought a wrapper ns_cache > > command could be added to the tcl/cache.tcl file. What do you think? > > You mean "ns_cache eval" -> "ns_cache_eval" stuff? Yes, just place > them there. There are not too many of them anyways. > When I look thru our code, we just use ns_cache (create, eval, flush) > so I will go and rename them to ns_cache_create etc. > > And, commit that code.
OK. It shouldn't cause any problems with existing code, and you can still load the nscache module, so I'll go ahead and we can see how it works out. It's only ~600 lines of code for the Tcl commands, and ~500 chopped out of cache.c, so I think it's going in the right direction. Still to think about are per-thread Tcl caches. The main reason for these are that you can put Tcl objects in the cache, not just their string rep, which is particularly useful for already-compiled byte code -- i.e. for *.tcl pages. The best solution for caching byte code might be to share the mechanism with ADP pages. They currently have a pre-thread cache of script blocks, and a per-server cache of text blocks, for each page. AOLserver 4.5 adds a per-server output cache. We could use this for *.tcl pages as well, perhaps negating the need for per-thread Tcl caches. That still leaves Tcl objects like lists or dictionaries that you may not want to stringify on each access. Input welcome...
