"Craig R. McClanahan" wrote:
> [...] Included servlets and/or JSP
> pages are about content (view in MVC terms), not modifying control (controller
> in MVC terms).
Huh... How about HTTP response... it's made of headers and data. Does
it mean that it's the data that is View. What about headers? Are these
headers a controler? Or maybe those are part of the view? So, why
internal subviews are stripped of some informations although they mimic
the general view model? Does that mean that entities that produce
included responses make a totally different model? Why?
> So what do you do if you've included three sub-servlets, and they all try to
> set the "last modified" header? Who is supposed to win?
Come on, do you really ask for the answer? Say, you have a more or less
static page, that you are able to state it's modification time was, say,
a month ago. But this page includes a subcontent. It was modified just a
minute ago? So is it impossible to guess what is the modification time
of the document that was composed from one that was modified a minute
ago, and one that was modified a month ago? Is this the kind of math
that is to hard to compute? :-)
> If you're talking about HTTP caching, that's done at the per-response
> level (usually an HTML page).
Sure. But to be able to markup the response with correct headers you
have to be able to compute their values. If you have no data about
included subcontents' validity, how can you say anything about the
bounding document? Of course - you can't.
Do you agree that correct validation mechanisms may improve performance?
If not, just look how HTTP/1.1 differs from HTTP/1.0, almost half of the
changes are related to response caching and cache validators. So, it
seems like this topic was important for the w3c guys.
Now, do you agree that for documents including other documents there is
absolutly no mechanism to produce per-response level validation headers
correctly? If you don't agree, tell me where should I look for them. :-)
The point is that even if we choose the simplest, lamest, laziest
solution, i.e. we put all the responsibility on providing HTTP/1.1
facilities on servlet authors, at least we have to offer them some
mechanisms to do it properly. That means that included servlet should
not be discarded from header information, but instead this information
should be at least stored somewhere and returned to the calling servlet
(for example in attributes).
-- Mike
___________________________________________________________________________
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
