Well, I sure got excited, though. Back to reality! ;-) <snip> > 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 "typical" setup, these requests would be handled by the > fronting web servers. It's clearly more resource-intensive in your > approach. </snip>
I am not clear what part of the process you are referring to, Frank. We both agree that the first delivery of the page is via the "front server" (I tend to only use the "back server" anyway). If there are ten calls to ten images, as you assume for discussion purposes, then there will be ten calls either way. I think you are saying that in addition there will be a penalty of a pass to a server that can handle Servlets or an equivalent technology that will respond to the ProtocolPage by routing the call to some Action, Command, or whatever in some language, in the way I suggest. Is that right? If so, let me know and we will go from there after you confirm. <snip> > Agreed. I do see the advantage of this approach, but it's the minuses > I'm more concerned with. No matter which way you slice it, there's more > server resources being utilized. That's a big minus when your talking > about scalability. </snip> I wouild need, as you would too I assume, more information on the actual penalty. I suspect that it is relatively small and, when you introduce sophisticated state and caching options, it may be faster. I don't dismiss what you are saying. Don't get me wrong. I just have learned to get the data and then to see what the real difference is. When considering costs and so on, I am not sure whether the balance goes to which side. I would suspect, from my experience, that software maintenance and so on would clearly outweigh the hardware and associated requirements. <snip> > I think you point out some valid advantages... if nothing else, just > doing away with having to deal with URLs is a very good thing. But I > think the performance hit, and certainly the server load, in a "typical" > Enterprise environment, would make this not a great idea. </snip> I am surprised at this. You may be right, but my sense is that this difference is not really that important when everything else is taken into account. Even if you had to cluster multiple machines instead of one, say, as a ratio, that would seem to be *probably* cheaper as a GUESS. I don't know. We could look at some data and if you have any handy I would love to see it. <snip> > Then again, I say the exact same thing about ASP.Net and JSF because the > whole idea of calling a server for relatively simple UI events strikes > me as a horrible idea until we have far better networks than we have > today, and I seem to be in the minority there, so if I might be wrong > there, I might be wrong here too :) </snip> I think the bigger hit is reading the danged thing. This obviously is especially so when there is an ongoing use of changing the JSP page. This has no penalty with ProtocolPages. <snip> > My wife wouldn't agree with the listening part :) </snip> Well, I bet you are being too humble. I am happy to say that my wife just thinks I am the most adorable, wonderful, guy. Go figure, eh? <snip> > I think in enterprise-type environments this is a pretty standard > approach with fairly well agreed upon benefits. Anything that breaks it > has to exceed those benefits. As my father used to say, that's a tough > nut to crack! Nothing wrong with trying to build the hammer though :) </snip> Technology seems to get ahead of rumor in our little world of web work. So, I definitely would like to revisit this. I am going to squeeze getting the *facts* in here soon. <snip> > Absolutely it is, but as I pointed out, it's being interpreted on the > browser side. That's where the issue comes in to play I think, > especially in a distributed environment. I'd be interested to hear your > thoughts on this point... </snip> This seems to be false to me. Maybe I misunderstand you. I don't think the browser has a clue whether we are looking at src='myCss.css' or src='resource.do?file=myCss.css'. Right? 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]
