On Wednesday, 13. September 2006 20:42, Kjetil Kjernsmo wrote: > I think that in a pipeline, the possibility of caching all along the > pipeline would be nice in some cases, so that certain requests will not > be passed all the way down to the DB, even though the served resource > is a composite of several components.
This is what cachecache can do for you. Sure, you will need to do your own expiry/dependency tracking, but I guess it's not hard for you to implement a generic method to do so cheaply. And cachecache allows you to fully control caching, since it is manual, nothing is cached automatically. All attempts at automatic dependency tracking sooner or later failed in AxKit2, so now you get to do it yourself. But As Matt already said, I'd check if it is really needed. Caching always adds an overhead, and perhaps your bottleneck is somewhere else. > I envision that HTTP's caching specification could also be used > internally in the pipeline, so that if you suddenly decide to throw a > part of the pipe away, the client or a proxy will still see and use > HTTP headers for caching. How should that work? Clients cannot be aware of your pipeline structure. > I haven't had time to look properly into Ax2, and I now recognize the > value of patches more than I did back when I started, but since you > asked, then yeah, a caching infrastructure is a very compelling > feature... :-) Well... up to now, I'd say "no". AxKit2 performance is great, you should really go and check it out yourself. Maybe manual caching is more than sufficient. -- CU Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
