Graham Leggett wrote: > This is a cryptographically signed message in MIME format. > > --------------msCEBA12FF9ED7450117A571A8 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Ian Holsman wrote: > > >>I was wondering if it would be better if we replaced >>how it slots in so that instead of IT pushing filters >>onto the output chain and relying on the 'quick' hook >>it could be done like >> >>http://holsman.net/test/cache.png >> >>where the CACHE filters are specified via setoutputfilter/setinputfilter >> >>I think this would be better because >> a) we could cache intermediate results if needed >> b) we could cache subrequests >> >>So what do you guys think of it >>this design asssumes that we could short-circuit all the hooks >>is this possible? >>
unfortunatly I couldn't get the input filter working at all. and due to this I don't even thing you can do what I proposed. thats why the quick_handler hook was modified so that it is in the internal_request now. > > The basic concept of the original design is that in its default config, > the cache would try to maximise performance as a primary goal. To > achieve this CACHE_OUT would have to be as close to the very first > filter as possible, and CACHE_IN would be as close to the very last > filter as possible, so as to "cover" as much of the apache filter chain > as it can. yep.. agreed, but if you can't configure it then it is next to useless for large sites where parts of their page are always dynamic. the current design might serve a page, but it ignores things like notes, which makes logging hard. > > Adding additional configurability so that things like subrequests, etc > can be cached is a good thing, however the original design goal - ie > maximise performance in it's default config should be kept. it is. it is. nothing I intend on doing will >require< an extra config directive. for caching subrequests, all that is required IMHO is to change the SUBREQ_CORE outputfilter so that it runs as a '20' not a '10'. there is a bug somewhere in the CACHE_OUT filter which is causing it to not act nicely.. but thats a bug, not a config option. > > I'm worried that with all the additional functionality, actually > configuring the cache will be a source of confusion. Currently people > can set caching on or off based on URL prefix - if they have to fiddle > with the filter stack manually in addition to this it will become too > complicated to use. how about this. if the filter-stack is in place, it will use it, if not it will add it. from what I can see in the code, it already does this. > > Regards, > Graham >
