I don't understand. Why is using "tempdir" not a long-term
solution? I see no contradiction between using a tempdir and being able
"to return images that get cached". You seem to be concerned about
client-side caching, while I am talking about server-side caching. My
point is that even if two different browsers hit the same Page, it
shouldn't regenerate the dynamic image if it doesn't need to --
regardless of whether the client has the image cached or not.
Gili
On Tue, 4 Jan 2005 11:52:50 -0800 (PST), Jonathan Locke wrote:
>yeah, but this isn't a long term solution. we ought to be able to return
>images that get cached... even dynamically generated ones. there ought
>to be a way to fudge the rendercount stuff so the browser will cache
>images.
>
>On Tue, 4 Jan 2005, Johan Compagner wrote:
>
>> You can write to disk in a webapplication
>> Use the work dir:
>>
>> ServletContext.getAttribute("javax.servlet.context.tempdir");
>>
>> That will return a File object that points to the work dir for the
>> current webapplication.
>>
>>
>>
>> Gili wrote:
>>
>> > Ok, so to rehash some points:
>> >
>> >1) Currently we parameterize the image URL on the session ID and
>> >parameters used to render the image
>> >2) We write out the image to disk somewhere (although I don't know
>> >where, can you elaborate?)
>> >
>> > My personal requirements are:
>> >
>> >1) Render image once per page, not per session or view.
>> >2) Do not expose image parameters if possible. Ideally the URL should
>> >read "image<number>.<extension>" and we'll have some lookup table
>> >somewhere that maps image creation parameters to image URLs -> reuse
>> >the same image if the same parameters are used (server-side).
>> >
>> > I remember reading about JBoss not giving you write access to
>> >the webapp dir (heck, you could be running inside a JAR). I feel this
>> >problem related to handling links to images in general, not just
>> >dynamically generated ones, if their URL falls under the servlet
>> >context path.
>> >
>> > What we could do (solves all problems I know about) is handle
>> >image URLs within the WebApp servlet itself. That is, we never write
>> >the images to disk if they're dynamically generated and "cacheDir"
>> >(some new property I made up) is not set. For JBoss and others cacheDir
>> >will be unset so it'll default to caching in memory. For Tomcat and
>> >others, it'll be set to the default temporary directory for the webapp
>> >so we'll cache to disk. What will happen is that someone will refer to
>> >/MyWebApp/myImage.jpg -- the servlet will recognize that the URL refers
>> >to an image, use the appropriate resource location mechanisms -- and
>> >stream back the image (whether dynamic or static). And ideally we'd
>> >throw in a "image parameters -> image URL" mapping somewhere so we
>> >don't have to expose inner details to the HTTP clients.
>> >
>> > My only concern is that for JBoss, dynamically generated images
>> >would be expensive. Still, I don't think we have a choice in such cases
>> >if we absolutely cannot write to any directory. What do you think?
>> >
>> >Gili
>> >
>> >
>> >On Tue, 04 Jan 2005 15:45:50 +0100, Eelco Hillenius wrote:
>> >
>> >
>> >
>> >>None yet. We're thinking about it.
>> >>
>> >>Eelco
>> >>
>> >>Gili wrote:
>> >>
>> >>
>> >>
>> >>> I saw a lot of discussion of the various problems and possible
>> >>>solutions but none of them was agreed upon because they each had their
>> >>>own problem. All I know is that in my case the dynamically-generated
>> >>>images should be treated as cacheable because they will not change with
>> >>>clicks (i.e. reference count). What is the proposed solution?
>> >>>
>> >>>Gili
>> >>>
>> >>>On Tue, 04 Jan 2005 13:03:00 +0100, Eelco Hillenius wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>-------------------------------------------------------
>> >>The SF.Net email is sponsored by: Beat the post-holiday blues
>> >>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> >>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> >>_______________________________________________
>> >>Wicket-develop mailing list
>> >>[email protected]
>> >>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >-------------------------------------------------------
>> >The SF.Net email is sponsored by: Beat the post-holiday blues
>> >Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> >It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> >_______________________________________________
>> >Wicket-develop mailing list
>> >[email protected]
>> >https://lists.sourceforge.net/lists/listinfo/wicket-develop
>> >
>> >
>> >
>> >
>>
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by: Beat the post-holiday blues
>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>_______________________________________________
>Wicket-develop mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
