Tim Williams wrote: > On 1/30/06, Upayavira <[EMAIL PROTECTED]> wrote: > >>Tim Williams wrote: >> >>>I want the image reader to accept a variant name (e.g. "thumb", >>>"small") and then write the newly created image variant to disk before >>>sending the output. In other words, so that a given image >>>"IMG001.jpg" might be "read" with a variant "thumb" and on disk would >>>now be: >>>IMG001.jpg >>>IMG001.thumb.jpg >>> >>>Obviously, a hefty cost for the first time through on each image but >>>just reading afterwards. I've initially done this by just copying the >>>entire ImageReader into a new PersistentImageReader and inserting the >>>applicable code in setup() and processStream(). Now that it's working >>>how I'd like, I figured I'd just extend the ImageReader and only >>>implement these two methods. The only way I can think to do it is >>>somehow redirect the output into a buffer, write the buffer, then send >>>it out. Is there a better way to extend a reader? Anyone have any >>>clues as to how I might be able to buffer the ImageReader's output? >> >>Well, sounds like you're trying to achieve something similar to caching. >>I wonder if the caching system might be an alternative approach to >>achieving the same thing. >> >>Anyway, to answer your question directly... >> >>The AbstractReader class has a setOutputStream method. You could, in >>your generate() method: >> * check to see if the resource has already been generated. If it has, >> set the inputSource to that of your cached version and proceed as >> normal (calling super.generate()) >> * Otherwise, take a copy of the existing output stream, set the output >> stream (using setOutputStream) to your own buffering version. Proceed >> as normal. At the end of the generate method you write the contents >> of buffer to disc, then copy contents of buffer to original output >> stream. >> >>I think that would work. And this should work as an extension of the >>ImageReader class as you suggest. >> >>Have I understood your question? >> >>Regards, Upayavira > > > Exactly, I'll give these a try and see what I can manage. It is > essentially the same as caching but I need something that can work in > both webapp and cli modes in forrest.
Ah. And currently the cache doesn't survive restarts in the CLI, which it should. So your approach is now more understandable. Regards, Upayavira
