jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Winterfeldt <dwinterfe...@yahoo.com>
Subject RE: Image taglib
Date Thu, 06 Dec 2001 04:01:20 GMT
I know it sounds like you are working on a more
elegant solution, but I made a custom tag that you can
point at a file (test.jpg) and it will look for the
the same with '-thumbnail' at the end
('test-thumbnail').  If it doesn't see the thumbnail
file, it generates it to the same directory the
original file is in.  There is also an directory
iterator tag that ignores files with '-thumbnail'.  If
anyone would like the source, they are welcome to it.

David

--- Shawn Bayern <bayern@essentially.net> wrote:
> On Tue, 4 Dec 2001, Abey Mullassery wrote:
> 
>  > I couldn't get the "the advantages of delayed
> image generation aren't
>  > worth the "fragility" of needing to re-engineer
> communication each time
>  > we decide on a new kind of image" part.
> 
> The goal is to avoid needing to modify the servlet
> (and the protocol
> between the servlet and tags) every time we add a
> new image
> characteristic.
> 
> The design I'm suggesting isn't described by either
> of your two
> scenarios.  Instead, it works as follows:
> 
> 	1. Browser calls a tag containing the JSP image
> action.
> 	2. The image action generates an arbitrary
> BufferedImage
> 	   and sends it to the servlet (e.g., as a method
> parameter).
> 	3. The servlet generates a unique ID for the image
> and sends
> 	   it to the image tag handler (e.g., as a method
> return value).
> 	4. The tag returns a link that embeds the ID:
> 		/app/servlet/image?id=0A5B57CC4Ajt
> 	5. The user follows this link (perhaps implicitly
> as an <img> tag)
> 	   and hits the image server, which looks up and
> vends the
> 	   previously generated image.
> 
> The other approaches require the servlet to be
> re-engineered for each new
> feature.
> 
>  > An image may be requested at any time later, even
> months later, for
>  > eg., if the url was saved. The image will not be
> in the cache till
>  > then nor can we save the lookup table for all
> IDs. So it is best to
>  > take care of image generation when the image is
> requested as a
>  > standalone process. In short step-a in scenario
> #1 and scenario #2 may
>  > occur anytime in the past and the rest can occur
> sometime in the
>  > future.
> 
> Yes - this is true.  I suggest we avoid targetting
> that case in favor of a
> design that remains simple for the vast use-case. 
> (These images, like
> most dynamic content, are best not thought of as
> "permanent" resources.)
> 
> Furthermore, caching images versus caching
> parameters is not conceptually
> different; if the image servlet simply caches image
> filenames and
> parameters, the servlet would still need to know how
> long to cache this
> data, under what circumstances to expire it, etc. 
> The only difference is
> the size of the cached data, which in most cases
> isn't going to be
> meaningful.
> 
> Again, this is just my opinion, but I think any
> other design is going to
> be excessively complex and not meaningfully more
> general.
> 
> On Mon, 3 Dec 2001, Bob Lee wrote:
> 
>  > I already posted something on this.
>  > 
>  > The best way is to use templating.
>  > 
>  > Here's an example:
>  > 
>  > <jakarta:image>
>  >     <jakarta:template>
>  >         <lots of randomSVG to render title>
> 
> But what if capabilities beyond SVG are desired?
> 
>  > Rendering the image in the tag and then
> displaying it in the servlet
>  > spawns a host of potential issues. For example,
> if the user has their
>  > browser set to not download images, do the
> rendered images just sit in
>  > the session until it expires? And if you GC the
> images manually, how
>  > do you handle the case where the use requests an
> image that has
>  > already been collected. Not very elegant.
> 
> All dynamic content faces this problem; a dual
> "image servlet / tag
> handler" that creates, caches, and vends information
> would be no different
> than a JSP page that links to another JSP page.
> 
> HTTP has sensible response codes we could use to
> indicate failure.  "HTTP
> 410" means "resource gone," for instance:
> 
>    The requested resource is no longer available at
> the server and no
>    forwarding address is known. This condition
> SHOULD be considered
>    permanent. Clients with link editing capabilities
> SHOULD delete
>    references to the Request-URI after user
> approval. If the server does
>    not know, or has no facility to determine,
> whether or not the
>    condition is permanent, the status code 404 (Not
> Found) SHOULD be
>    used instead.  This response is cachable unless
> indicated otherwise.
> 
> I'm not sure I see the problems with elegance in
> delayed vending.  The
> situation is imperfect, but it intentionally targets
> a particular
> use-case.  Images that are meant to be permanent
> ought not to be created
> and vended by dynamic web pages!  :-)
> 
> To answer your specific questions, I would propose a
> configurable timeout,
> and perhaps automatic expiration after a single
> retrieval.  An alternative
> design would be a circular "image buffer" kept with
> the session, so that
> images are available unless other images (or, e.g.,
> images of a particular
> size) force it out of the cache; in combination with
> a timeout, this might
> best represent the behavior that page authors would
> desire.
> 
> Shawn
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:taglibs-dev-help@jakarta.apache.org>
> 


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

--
To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>


Mime
View raw message