In regard to our caching discussion, Frank, I think you will like the
following article. The prior article about two essential filters is
interesting too.
http://www.onjava.com/pub/a/onjava/2004/03/03/filters.html?page=1
One thing seems certain: there is complete serverside cache control.
--
"
Dakota Jack wrote:
The good is that the web site designer knows when a change has been
made and the assumption is that you are going to see what the web site
designer has to offer. No?
Jack
I concur with the assumption, but I don't see it making any
difference... Remember that what we affectionat
On Sun, 30 Jan 2005 14:11:24 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> I still don't understanding the 32 and 22... What do the [2] and [3]'s
> represent?
A total of three possible processes (1) getting the request; (2)
passing the request to another server; (3) handling the response
> The question that's in my mind though is what happens when you have a
> web server in front of Tomcat? Just "rendering to the response" in a
> servlet might not be enough in that case...
*Before* ResourceAction returns null, the response output stream has
been written, flushed, and closed.
I still don't understanding the 32 and 22... What do the [2] and [3]'s
represent?
Dakota Jack wrote:
Too late when I sent this. Let me make the necessary alterations to
the nomenclature. Sorry!
web server = df. (WS)
app server = df. (AS)
request= df. req
response = df. res
> = df
Dakota Jack wrote:
I am certain on this one, because you can do this sort of thing
*without* the web or app servers at all. I do this fairly frequently
with code not unlike and heavily borrowing in principle from Jason
Hunters HttpMessage and HttpsMessage in COS. The ResourceAction sends
the resp
Too late when I sent this. Let me make the necessary alterations to
the nomenclature. Sorry!
web server = df. (WS)
app server = df. (AS)
request= df. req
response = df. res
> = df. passing the control
With ResourceAction
1.0 WS req WS res HTML [2]
1.1
> > I think that the ResourceAction class actually acts as the web server
> > and that is why the return is null. The class writes to the responses
> > output stream and that is all the server does, right?
>
> I thought so too at first, but upon further reflection I'm not so
> sure... If a reque
Dakota Jack wrote:
app server = (AS)
struts server = (SS)
req = request
--> = pass
res = response
You lost me here already... What's the difference between the app server
and the struts server? Isn't Struts running IN your app server?
With ResourceAction
Dakota Jack wrote:
I just mean the more complicated parsing rules that go with JSP, as
well as everything else.
Ok, gotcha. But, this only applies for the first access to the JSP,
right? From then on it's a servlet invocation (which is more expensive
than returning just a plain'old HTML documen
I think the worst case is 22 versus 32, Frank. with 10 images. See
your note and then my reasoning below that.
> Even if it's all done in the most efficient way, those ten requests
> look, for all intents and purposes, like 10 simultaneous USERS (assuming
> 1 request per user). So, maybe your
> > I suspect that it is relatively small and, when you
> > introduce sophisticated state and caching options, it may be faster.
>
> Relative to what? To the web server dealing with it? I would suspect
> it's actually relatively BIG compared to that. I'm certainly willing to
> be proved wrong
I marked my response as OT, I think we're going down that road (not
exactly unusual for us)...
Dakota Jack wrote:
What I was getting at is the fact that if I return a page to the browser
that have ten images, all referencing ResourceAction, what's happening
is that the browser is making ten separ
Well, I sure got excited, though. Back to reality! ;-)
> What I was getting at is the fact that if I return a page to the browser
> that have ten images, all referencing ResourceAction, what's happening
> is that the browser is making ten separate requests TO THE APP SERVER,
> whereas in a "typ
Dakota Jack wrote:
I am going to tell you something that you might have missed. There is
no need to have a JSP page to do this. This is NOT dynamic content.
This is strictly HTML.
I fully understand that. Keep in mind that a recent project I did
required that images be served out of a databa
Hi, Frank,
Always good discussing these matters with you. I think you are going
to get a kick out of the turn this reply to your response will get. I
AM GOING TO REVEAL WHY I THINK THAT THE BASIC STRUTS ARCHITECTURE, AND
.do IN PARTICULAR, IS THE WAVE OF THE FUTURE, NOT THE PAST. [Imagine
"Miss
16 matches
Mail list logo
