On 22 Mar 2007 14:58:15 -0700, Kev <kevinjamesfield@xxxxxxxxx> wrote:
Hi everyone, I'm still in the design phase of a project. I was just wondering if anyone has any thoughts or experience on the idea of cutting the P out of the LAMP (or in my case, WAMP for now) stack. What I mean is having everything encapsulated into sql (or plpgsql or plperl where needed) functions stored in the pgsql server, and have Apache communicate with pgsql via a tiny C program that pretty much just checks whether the incoming function is on the allowed list and has the proper data types, then passes it straight in. Any errors are logged as potential security breaches. I'm really new to mod_perl too, so another question would be if this would be much faster than a simple perl script that did the same thing. I ask this because I realize I need to carefully check data coming into pgsql functions as well as at the client end. Why maintain a bunch of scripts with names similar to the functions they're calling and all performing similar checks anyway? I was kinda salivating at the thought of how fast things would be if you cut out the A as well, by using a Flash applet to give socket access to JavaScript. But then I guess you have to make your pgsql server itself publicly accessible on some port. Is that just asking for trouble? I appreciate any comments or thoughts anyone might have on this.
IMO, I think 'thin middleware' approach is a great way to design applications...so you are right on the money. The web server. IMO, should be mostly concerned about rendering html. I don't think eliminating the middleware is really practical. While you could use a thick-client javascript framework like GWT and write your queries in javascript (getting data back via json), I don't think it's really possible to secure this properly without killing the 'ease of implementation' factor. Then again, it's no worse then your typical old school visual basic or delphi in-house application so common in the 90's. I really miss the simplicity of Delphi. merlin
