On 27/03/07, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
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.
Strangely the in-house application is often still the better way to go. The web can make everything 3 times more complicated than it needs to be. Toolkits like GWT help this but you still need to write "middleware" even when you can trust the trust the end user. Hence most places still use in-house applications except the VB or Delphi gets replaced with Ruby or Python. Here we use C++ and Qt but thats another story. The web should still be used for mass market apps and heavy communication apps and not standard desktop answers. (Unless you particularly like writing everything twice) The secret is to use the right tool for the right job, and not try and find the does everything spanner that fits all nuts and also undoes screws too. Its never going to work in every case. Unfortunately some people like this idea. Peter.
