Throwing my 2 cents into the pot....
Geoff wrote:
> Craig R. McClanahan wrote:
> >
> >Geoff, I haven't used getLastModified() a lot -- it's pretty useless for
> 100%
> >dynamic content -- but it seems to do what I wanted when I used it. See
> >further comments below.
>
> Yes, exactly. Here's my reasoning that follows from this...
>
> 1) getLastModified is pretty useless for dynamic content and
To reiterate what Craig R. McClanahan said: it's useless only for 100% dynamic
content. My opinion is that most content isn't 100% dynamic. And if a site's
usage indicates that a user will request the same information often between
information updates, it makes sense to cache it on the browser's end to save
both the expense of reprocessing it and the time to transmit it to the browser
(or proxy server). No? This is not an absolute, a developer should only take the
time to implement caching only if it improves performance in a real-world
setting.
The typical example, say the user is flipping thru an online store's products.
What is 100% dynamic (ie, _always_ changes between a user's viewing of it)? The
products' info doesn't change that often (and if it does then we can make sure
getLM knows about it) - so we can cache that. The frame on the left (or on top)
indicating the product categories and subcategories doesn't change often (but is
still dynamic in the sense that humans don't go around writing the HTML for
it) - another thing to cache. The advertising images/links change but one can be
quite clever about abstracting these and having both the links and the images be
handled by other servlets.
For example, a MyWidget of Subcategory, MySubcategory, of category, MyCategory,
could be at this URL:
http://www.mybusiness.com/servlet/CatalogServlet/MyCategory/MySubcategory/MyWidg
et
The first time a specific user, requests it, getLM() returns -1, and the page
gets composed and returned and tagged with a LatsModified stamp (see below). The
next time, the same user requests it (assuming their browser cache hasn't
cleared it out), the servlet (thru service() method) merely says: you already
got a copy, use that one, just like static HTML. :-)
How does getLM() work?
It caches the PathInfo (ie, the "/MyCategory/MySubcategory/MyWidget") with the
last time anything on the page changed (for examle, in a static synchronized
hashtable in the servlet would be ok on a one-VM architecture). The lookup is
cheap (the cache can be maintained by another thread). The cache could be
loaded/saved with the servlet's init/destroy if so desired. If MyWidget changed,
the maintenance thread would be notified and the key/value pair trashed. If
MySubcategory changed, same thing. In general, if any number of other
page-changing events happened (servlet developer gets to define them, the
maintenance thread gets to listen for them), the maintenace thread chucks the
cached timedate stamp.
Instead of using PathInfo the QueryString could be as the key too I suppose.
One could get fancy by having the LastModified cache do wildcard matching too
(ie, "/MyCategory/*" be cached with the category's LM).
For personalized pages, one would need to scope the LastModified cache by
session (or maybe "application") as suggested earlier (but that's only so that
it would work across proxy servers). Again only if it's worth teh effort. Unlike
Geoff, I don't see an architectural problem with using the session to store
user-specific information, that's where one would put a shopping cart after all.
The point of the LM cache is to put the calculation burden on doGet() and to use
a fast getLM() method in order to avoid using doGet at all.
I am making this up as I go along, and haven't tried it. So yell if I made a
mistake...
> 2) servlet engines usually include a FileServlet that's perfect for
> delivering static content :-) (and even that probably overrides service()
> rather than using getLM()), thus
Yes it does, but that's because it's a very specific implementation of
HttpServlet, ie, one that can't handle CGI requests (of any kind). Anyway, a web
server is quite good at handling static content... :-)
> 3) getLastModified() is effectively useless in most situations, and it
> should be deprecated, and
No, not another way to ruin my old code. :-)
> 4) if we want to support this functionality in the servlet api we ought to
> design a more _functional_ replacement.
How could conditional GET be more functional (within the confines of the HTTP
spec)? Support entity-tags?
-s
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
