>>> Geoff Soutter <[EMAIL PROTECTED]> 9/17/99 7:13:44 AM >>> >Yes, exactly. Here's my reasoning that follows from this... >1) getLastModified is pretty useless for dynamic content and So is ANY caching mechanism (dynamic content changes, therefore can't cache). >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 Do you KNOW if the FileServlet's don't use getLastModified()? What about JSP? Implementations of BOTH of which use getLM. >3) getLastModified() is effectively useless in most situations, and it >should be deprecated, and This is just nonsense. Why not depreceate getServerName() as it is useless in _most_ situations. It's only usefull when you need it. >4) if we want to support this functionality in the servlet api we ought to >design a more _functional_ replacement. Why is this not functional? Nic Ferrier Tapsell-Ferrier Limited http://www.tapsellferrier.co.uk "Use Ockham Luke" >>> 1) it doesn't allow you to easily share state with doGet(), which you almost >>> always want to do >Yes, you could do this, although considering the high level of binding >between getLM() and doGet(), this seems overkill to have to use the session >to communicate. I wouldn't consider the use of the session in this case >'easy' - although I'd be prepared to accept 'standard' ;-) When do you need to "share" state? getLastModified() operates on a url (bound to a resource) to record and state whether that resource has been altered. It doesn't provide any other functionality, that's all it does - short and sweet. >>> 2) there's no easy way co-ordinate error handling between getLM() and >>> doGet() (you can't even throw a ServletException from getLM()). >>If I suspect there is a problem, or run into difficulties calculating the >>timestamp to return, I return -1 from getLM and let doGet() deal with it. >Why not just abandon getLM() and do it all in doGet() then? Otherwise you >are duplicating effort... Because getLM() is perfect and doGet() is NOT. And NO you are not duplicating effort. getLastModified... repeat the name to yourself till it rings a bell, the method does this: it gets the time the resource was last modified, or -1 if it can't. It doesn't handle errors, bicycle up cliffs, or teach elephants to sing. It just does it's job. doGet on the other can do whatever you like. How would you do it in doGet()? You'd just be creating more work for the programmer. By taking away a perfectly good method you're forcing people to have to think about how to do it. If you have an out of date resource how do you return the date? If not do you throw an exception? You're asking the programmer to do MORE work here. getLM() is nicely encapsulated in the HttpServlet so people who don't know what it's for don't have to touch it. >>> 3) getLM() will set LastModified even if doGet() fails and throws an >>> exception. This means that the client will try and cache your "error" >>> (unless you do a sendError() or somesuch). >>I have found this to be true with static HTML pages as well. Have you ever >>pressed STOP during a long page display (in Netscape Navigator), see the >>"Transfer Interrupted" message, and you can't get rid of it, even by >>Reload? The last time I looked at this, I concluded it had to be based on >>conditional GET responses because I've got Netscape configured to check for >>updates "once per session". >I hadn't though of that, but a dynamic page is a lot more likely to fail >than a static one.. ;-) Why? Because it is changing more often? Then don't cache. Forgive me, you seem to want something more than what getLM was designed for. It is designed to support the static page serving functionality that is still needed under servlets. It is not for control of dynamic content because dynamic content is difficult to control. For what it does it works _very_ well (acheiving simplicity and style and function - a rare thing). >>> I suggested that making the logic in gLM() available to be called from >>> _within_ doGet() would be much more useful in general. >>Given that the service() method needs to call getLastModified() before >>doGet() -- to decide whether to send a NOT MODIFIED response back -- that >>seems to defeat the purpose. >I think maybe I didn't explain that one very clearly. I was thinking of >deprecating the old gLM() and having a an alternative like a helper method >you could call inside doGet() to encapsulate the header name, etc. Obviously not. How is this different from getLM()? You just stop the HttpServlet from doing the work instead of the doGet writer. You make the doGet() writer go and get the date and compare it? Well, surprise! that is not what getLastModified does. If you want to do that you can, quite easily. There is NO PROBLEM with doing this: long x=request.getDateHeader(LASTMODHD); if(x<SOMEVAL) .... And if you want to do this - go ahead. Just don't ask for getLM() to be depreceated because you have a rare problem with conditional GETs. >I dunno, there must be a better way to do it! :-) Sorry Geoff, to be so up-tight about this but some of us have been defending getLastModified() from attack in some other quarters recently. I don't mean to be rude, but I believe it comes from not reading and understanding the spec. I don't understand _any_ of your stated reasons for depreceation. I don't understand what you want instead? ___________________________________________________________________________ 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
