On Sat, Jun 24, 2006 at 04:30:26PM -0700, Andrew Lentvorski wrote: > Lan Barnes wrote: > > >And I would miss these because ...? > > Because there are good uses for Javascript. Much like the initial > horrid abuse of Flash, once people start to figure it out, it becomes a > useful tool. >
-snip of good uses for JS- I'm not attacking the apache/javascript axis ... OK, I am, but not that much. I'm questioning how JS pertains to what I said, which was: 1. I wouldn't do a c/s program with a browser interface unless forced to (as in by a PHB or because I'm Amazon and can't distribute my front end) 2. if forced to, I wouldn't choose apache, but rather something more light weight, mentioning Tclhttpd You responded that I would thus loose the richness that is javascript, and I said (in effect) so what? Here's why I feel that way (and I say this with great respect for apache). Good c/s design is: FRONT END <--> MIDDLEWARE <--> BACK END Middleware is business rules, processing, magic. I don't care where it lives, but likely it'll be on the back end server or its own server where I can: a. have one production copy b. have security and control c. not deal with the headaches of distribution and supporting multiple versions. Now we all tend to want to push the middleware to one end or the other, because writing the extra interfaces is a pain, and the temptation is to push it to the front end BUT THIS SHOULD BE RESISTED (raise a chant: "Thin client, thin client ..."). Integrity checking and data massaging DO NOT belong in the front end and required fields should NEVER be enforced in the form. Send your data over to the server and let the server either fix it up or send back a scolding message. So now you're telling me that I'll miss javascript because without it, I can't do cool processing on my client. Hmm ... is Andrew telling me that I should not just want a FAT client, but an obese client, a client with its waistline flowing over its belt? No thank you. "But," you say, "the whole reason for thin clients is to avoid the hassle of continuously redistributing updates and supporting a variety of versions. And javascript on a browser gives you a universal platform on which your server can call for nifty client actions, kinda like inter-machine call-backs." To which I say, how universal has it proved to be? How many flash modules, JS implementations, language stubs, etc am I expected to load? Must I use IE? How much does it buy me? What is the bang for buck in terms of programming effort? Is the single platform the ONLY reason for thin clients (hint: hell no! Think design and coding simplicity with concomitant robustness)? And is there, perchance, a tiny security issue in letting unknown people run stuff on your machine? So I say again, I wouldn't do a c/s program with a browser interface unless forced to. And if I did, javascript (and flash and whatever other goodies du jour are about) would be rejected from my design. Not ignored, rejected. Now Tclhttpd has some features designed to make my kind of approach easy. http://www.tcl.tk/software/tclhttpd/ for everything, http://www.tcl.tk/software/tclhttpd/TCLHTTPD.html for a nice chapter from a good book. It was never meant to be an apache replacement ... how dull that would be! Sure, you can use it as a well featured web server if you don't need the apache bells and whistles (or are afraid to lift the apache book without a weight belt and steel-toed boots). And you can embed it in your own applications if you ever want a web server to be tucked into your own programs. But what really scratches Lan's itches are the Application Direct URLs, which basically means, hit this URL, trigger this back-end action. Of course, the back-end program can be in just about anything that runs on the platform, but if I write it in Tcl and use a safe interpreter, I really don't have to worry too much about security (assuming intranet or ssh tunneling), which is not the way I would feel about a fully tricked-out apache server, and certainly not javascript. And _even then_ I would resist doing a browser interface because It would require me to write everything twice and support everything in two places. Yuk! Keep it simple; make it work; go on to other things. Perhaps more of my philosophy that you cared to know, but there it is. -- Lan Barnes Linux Guy, SCM Specialist Tcl/Tk Enthusiast As a POW in Vietnam, I was kept in the dark and fed scraps. Why would I want to do that again? - John McCain on why he wouldn't want to be vice president -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
