Geoff Soutter wrote:
> Craig R. McClanahan wrote:
> >Geoff Soutter wrote:
> >> Nic Ferrier wrote:
> >> >But I am happy to applaud if Geoff or anyone else can give a reason
> >> >why getLM is derelicting it's duty.
> >>
> >> Nic, as I said before, you've only addressed one of the points I raised
> in
> >> my original message. Here they are again, perhaps you'd like to comment
> on
> >> the other two?
> >>
> >> 1) it doesn't allow you to easily share state with doGet(), which you
> almost
> >> always want to do
> >
> >Geoff, there was another message thread a couple days ago (dealing with why
> >frame reloading worked differently when a servlet created the frameset
> versus a
> >static HTML page), in which I offered a design pattern that dealt with this
> >issue. In case you didn't see it, the idea was this:
> >
> >* Don't implement getLastModified() explicitly
> >
> >* At the beginning of your doGet() method, define
> > the logic needed to determine whether the page
> > that this user has already cached is stale or not.
> >
> >* If it is not stale, do the following:
> > response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
> > return;
> > which is essentially what the HttpServlet.service() method
> > does for you if you do implement getLM.
> >
> >* If it is stale, or if the client does not have a current
> > copy of the page (i.e. no "If-Modified-Since" header),
> > go ahead and generate the page in the usual way.
> >
> >Now, since you're doing everything in one doGet() method in the context of
> a
> >single thread, there shouldn't be any state matchup or code duplication
> issues,
> >right? Of course, you still have to deal with state issues that cross
> multiple
> >requests, but that's a consequence of using a stateless underlying protocol
> >like HTTP. I deal with that by keeping the state in user sessions, where
> it is
> >equally accessible to both getLM and doGet.
>
> Yes, that's exactly what i am doing. What I was thinking was, can we encode
> this design pattern into the Servlet API so that anyone can use it, rather
> than just staying with the old way which wasn't working for me, ( and
> presumably for others who have similar requirements)
>
Isn't it already possible to use this design pattern if you want to or need to,
and ignore it if you don't? I don't see where adding anything additional is
going to make life simpler.
>
> >NOTE: Even if this approach deals with your concern, that doesn't seem to
> be
> >enough justification to deprecate a call that is being used by other
> people,
> >and disrupting their lives unnecessarily. :-)
>
> I agree. I was only suggesting that we deprecate the old getLM() if we
> designed a better, more fuctional thing.
>
> Also, deprecation of a call doesn't disrupt, it's _disablement_ of a call
> that disrupts, as many of us found out going from 2.0 to 2.1.
>
Deprecation disrupts developers, because it triggers warnings on every
compile. In addition, if you work in a shop with a rule that says "thou shalt
not use deprecated methods", it forces you to change your code even before the
underlying feature is disabled.
If you are not going to remove it ever, you shouldn't deprecate it.
>
> >> 2) there's no easy way co-ordinate error handling between getLM() and
> >> doGet() (you can't even throw a ServletException from getLM()).
> >
> >Not being able to throw ServletException hasn't ever bothered me. If my
> >servlet throws any exception from anywhere, then I consider my servlet to
> be
> >broken and in need of fixing -- whether caching works or not becomes
> >irrelevant. Your next point covers other aspects of error handling
>
> I can't actually remember the motivation for this point (many months ago). I
> agree in general about throwing exceptions.
>
> >> 3) getLM() will set LastModified even if doGet() fails and throws an
> >> exception. This means that the client will try and cache your "error"
> page
> >> (unless you do a sendError() or somesuch).
> >
> >I think there's at least a few different issues here:
> >
> >* If you do use getLM and it returns a time before
> > the if-modified-since header in the request, your
> > doGet() method will never get called, so it won't have
> > any opportunity to throw an exception or display an
> > error page. See above for my beliefs about servlets
> > that throw exceptions, but error pages are a legitimate
> > concern.
>
> Not sure I get this one. Why would you return a valid time from getLM() if
> you knew you wanted to send an error?
>
If you know in getLM that you are going to send an error page, you will want to
return -1 so doGet will be guaranteed to be called.
>
>
> >* If your app sends back an error page of some sort,
> > (say, input fields failed a validation test), then it's your
> > responsibility to remember that on the subsequent
> > request, so that you send back an appropriate
> > last-modified time that forces a reload of the "real"
> > page. This is true if you are using getLM or if you are
> > embedding your caching logic directly into doGet.
>
> Hmmm, sounds complex. Why not just prevent the error page from being cached
> by not setting the LastModified in the response? This is easy if you write
> your own, but if impossible using getLM().
>
The "Last-Modified" header is not set when you return -1 from getLM. That's
about as easy as it gets.
>
> >* If it's more convenient to combine the cache decision
> > logic in your doGet(), you're welcome to do so. But
> > getLM works for other cases -- and disrupting
> > existing running programs by removing functionality
> > doesn't count in my book as "improving" the API,
> > unless you offer a replacement that is demonstrably
> > better.
>
> See point above about deprecation != removal.
>
> >There's been some discussion on supporting caching in the API among the
> servlet
> >experts group that reviews new API specs before they go public (I am a
> >member). The challenge with caching is that it's very difficult to define,
> in
> >a standardized way, the rules to decide whether the cached version of a
> >response is stale or not. HTTP proxies have the same kind of issues for
> >caching static pages, and it's taken a *long* time for the rules refined in
> >HTTP/1.1.
> >
> >For any given app, this staleness decision might be based on combining any
> or
> >all of the following factors: logged-in user, request URI, query
> parameters,
> >cookies, HTTP headers, browser making the request (in case you keep
> different
> >versions for different browsers), time of day (you might be producing
> updates
> >on some sort of regular schedule that invalidates the cached copy) and so
> on.
> >Proposed solutions to this, IMHO, suffer from a level of complexity far
> higher
> >than any other concept in the servlet API, and don't belong there. Whether
> to
> >cache, and how to cache, seem to me to be application-level decisions, not
> >generic API level mandates.
>
> Yes, it's nasty alright. :-( But doesn't that make it even more important
> for the Servlet API to offer good support in this area?
>
IMHO, generic APIs like servlets need to stick to those design patterns that
are absolutely required for all apps (like the servlet lifecycle) or are widely
needed and can be implemented through *simple* interfaces (like sessions).
Otherwise, your API's complexity grows exponentially and it becomes unusable.
GUI application frameworks like MFC, and even complex APIs like Swing can fall
prey to this tendency.
Dealing with all the permutations of caching seems to me not to fit the
universality principle or the simplicity principle, but I could be persuaded
otherwise by a concrete proposal illustrating an elegant solution.
>
> >At any rate, recommendations to deprecate something like getLM are not
> likely
> >to be persuasive, simply on the grounds that it works now, and is being
> used in
> >existing programs. There's no overriding security issues like there were
> with
> >getServlet() and HttpSessionContext, so it doesn't even matter if something
> >else might really be a little better -- and there are apps for which getLM
> as
> >currently specified works just fine, and "better" simply means "leave it
> the
> >heck alone."
>
> Again, deprecation != removal. And I wouldn't suggest even deprecation
> unless there was a more functional version.
>
If deprecation does not mean *eventual* removal, it shouldn't be done.
Even if we added a caching mechanism alternative in the API, there's no
compelling reason to disrupt the people that are doing it themselves just fine.
>
> Geoff
>
Craig
___________________________________________________________________________
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
