Sylvain Wallez <[EMAIL PROTECTED]> writes: > > Stefano Mazzocchi wrote: > > > Pier Fumagalli wrote: > > > >> http://www.mortbay.com/MB/log/gregw/?permalink=servletNG.html > >> > >> Pier > > > > > > wow, what do you think it would take to create a CocoonServletNG? > > > Cocoon could return a Source object which, AFAIU is not that far from > Greg's idea of using the ContentHandler API. A FileSource > (e.g. returned > by a Reader) could then be memory-mapped by the container, and we may > even think of a container-managed cache where Cocoon just > computes the > validity. > > Just some random thoughts... >
A long time ago Stefano was bouncing around ideas about caching and some push/pull XML interfaces where being discussed. I suggested that maybe it might be possible to create a sort of normalized DOM/PVSI internal Cocoon database cache implementation that was push by SAX and pull by request. (This didn't get much interest at the time, probably because I have a hard time explaining the concept without a white board.) Think of it this way: if you've got a dozen different pages that are all small variations on each other you end up building completely different SAX streams for each of them (even if they can be cached). If instead you could annotate a sort of DOM model with key pointers that told you which nodes where relevant for which page requests you could normalize the cache. A reader or sorts would then walk the key chain for any given page request, pulling out the relevant nodes as needed. If the keys where memory location pointers you've got your memory map directly (you need a request key to result key mapping, but if you're normalizing you've to do something like that anyway, it's many to one). You could hide the normalization part (and you'd want to turn it off or have it run in the background if read wasn't very dominant over write), that's really just an internal optimization of the cache manager, so this sounds similar to what you are suggesting?
