<snip> > > 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. </snip>
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 response and ends the whole process by returning null. <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... </snip> Well, maybe on on an "operation" basis. An operation by any other name is still an operation. However, I don't disagree and would merely quibble about the language and the description. <snip> > 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. </snip> Well put! Yes! <snip> > But, because a Java program can be > optimized at runtime, that's where the speed gains occur that you can't > get with C. </snip> At the very least this is a main place to gain speed: the Tortoise and the Hare come to mind. <snip> >ceteris paribus </snip> Heh, I meant to tell you last time, this is Latin, not Greek. LOL ///;-) www.m-w.com Main Entry: ce�te�ris pa�ri�bus Pronunciation: 'kA-t&r-&s-'par-&-b&s, 'ke-, 'se- Function: adverb Etymology: New Latin, other things being equal : if all other relevant things, factors, or elements remain unaltered <snip> > 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) </snip> The answers are no, yes, no. Setting caching in the response object is not equivalent to setting caching in the <meta> tags. This is why the ResourceAction has an edge. Note also that the setting of cache, pragma and expires are runtime alterable, and can override the <meta> tags, in ResourceAction. I left those decisions out of the code I sent you. Did you notice where I added in it response to someone's query on that? <snip> > 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. </snip> And, if you imagined more radical uses of images for whole pages, etc., then you might start thinking about BufferedImages cached in sessions, etc. <snip> > I leave the leg-work to you :) </snip> You got it! Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
