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 document, right? But now I am splitting hairs)
Heh, heh! Remind me never to fence with you, Frank. Actually, and this is really off topic, in my milieu I am dearly loved because I have really learned how to be a friend, husband, etc. This has been the largest accomplishment by far in my life and the one I most cherish.
That's all that counts in the end. I have a wife of ten years and two great kids (well, most of the time they are great anyway), and although I have to remind myself of it sometimes because I get so wrapped up in other things that aren't as important, they are without a doubt my greatest accomplishment.
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 request comes in to the web server and then it forwards it on to the app server, that would mean at some very low level that the web server was passing along the connection to the app server... I'm not so sure it's anything that complex... It may be that the app server "renders" the response stream, but then passes it back to the web server to return to the client. The bottom line though is that we're talking a level low enough that I don't know the answer for sure.
> Again, I am not sure about this, and it is the sort of thing that one
typically makes mistakes about if one does not go by the data. So, I
am going to hold judgment on it, but my intuitions are not running in
the same direction as yours. I keep remembering how the following of
good OOP principles can make Java applications faster that C
applications doing the exact same thing, although most think that
would not be the case. Just the other day I was reading about a guy
who tried and failed to do some imaging work in early Java and had to
go to C. Now Java is faster in that area.
<snip>
I too await the data :) But, I think you'd have to agree that for your approach to wind up being faster, much like when Java programs are faster than C programs, it must be due to some hidden optimization going on. I mean, on an operation-per-operation basis, C will ALWAYS beat Java... Simply put, there will always be less machine code ops going on with a C program at the lowest levels (assuming they algorithmically equivalent) than a Java program. But, because a Java program can be optimized at runtime, that's where the speed gains occur that you can't get with C.
Something similar must be happening if your approach winds up being faster. All things being equal (ceteris paribus), that's the only logical conclusion to reach. That doesn't make it the right one of course :) The data will be the decider...
I think there are trade-offs that will need to be measured. For example, I can envision with some of the stuff I do creating whole pages dynamically with images. The new Java imaging stuff is really, really, cool on this. Flash has its side too.
No argument there... it's the same with OOP vs. strictly procedural code... if we assume we're always talking a straight compile to machine code and similar optimizations in both, procedural code should generally be faster for the same reason I talked about above. Clearly though, the benefits of an OOP approach outweigh any difference. Same could be true here.
> Now just one moment, Bub! LOL ;-) You really are not seeing the
ways you can save time here. For example, there is such a thing as
caching, pragmas and expiry headers which can be set with a response
in a way that the meta tags just cannot handle.
But now your pushing those caching decisions back on the browser, right? I thought one of your basic premises was to not trust the browser to construct URLs and such? Wouldn't you have the same distrust for caching? (and probably worse since that is at least at the users' discrection)
There will be savings of creating no calls where pure HTML would be lost. There will be other things like this too. Remember too that the ResourceAction class is acting as a multithreaded alternative mini-server. Indeed, the approach allows us to get the images, for example, from some other server that is maximized to do just this. Conceivably that could be quicker for cached images. Remember I said "conceivably". The ability to be flexible can make for great rewards in efficiency and fluidity that are not immediately obvious.
Granted, some additional flexibility might outweigh any problems. If you rolled my BLOBServerAction into your ResourceAction, then you could transparently serve images from WEB-INF *or* a database, transparently to the user and front-end. That's a nice bit of flexibility to be sure.
I don't say you are mistaken. I just think that this is going to be an interesting little inquiry, if you want to chase it to its end, which is my normal proclivity.
At this point I don't think either of us could walk away with an actual answer :)
I understand. All your comments are quite fair, in my opinion. We'll look around and learn a bit here.
I leave the leg-work to you :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
