Fwd: On-Rev mySQL security issues? -- or use an LC stack for the DB?

[Pierre Sahores]

Please replace below :

> get yourapplogics_code()

with

> get yourserver_response()

Début du message réexpédié :

> De : Pierre Sahores <sc at sahores-conseil.com>
> Date : 28 novembre 2011 11:47:37 HNEC
> À : How to use LiveCode <use-livecode at lists.runrev.com>
> Cc : Pierre Sahores <sc at sahores-conseil.com>
> Objet : Rép : On-Rev mySQL security issues? -- or use an LC stack for the DB?
> 
> Hi Tim,
> 
> In an "n-tiers" app logic build on top of LC-server, the best is to 
> 
> 1.- use a "script.lc" to bind the web UI+forms to the backend where the "script.lc" is just a couple of lines :
> 
> <?lc
> 
> try
> 
> 	start using stack "server_lib.livecode"
> 	get yourapplogics_code()
> 	catch tErr
> 	put tolocalisation("Maintenance en cours. Merci de renouveler votre demande dans quelques minutes...")
> 
> end try
> 
> ?>
> 
> 2.- start using a "server_lib.livecode"
> 
> 3.- and run the "yourapplogics_code()" function included in "server_lib.livecode" as the main controller of your LC-server application's logic
> 
> 4.- to code your server lib stack in launching it by a simple double-click from your (S)FTP browser app witch will directly opens it in your LC IDE with all the associated advantages (live debugger, app browser, changes directly saved to your server, etc...)
> 
> About the contents your server has to handle and to preserve the advantage of the "n-tiers" multithreading architecture LC-server give us, don't handle/manage data as stack's or flat files components but bind them instead from a PostgreSQL (best !) or other SQL backend.
> 
> In this way, you will get the best production's performances and rock solidity in letting the different components of your "n-tiers" app works at its best level in "parallelized mode" where any new client-side request will be handled in its own fast running thread because the Apache+LC script+LC server lib+PostgreSQL process will no contains ways to slow down this collaborative thread.
> 
> If you use stack's datas or flat-files instead, your LC-server will become less responsive and possibly very problematic if your server has to handle more than some requests peer second, while in using a fair distribution of your app logics in between the components as described before, your app will be able to handle any client-side connection at its best level, even with hundreds connections peer seconds (in letting Apache automatically and cleanly queue them if needed).
> 
> HTH,
> 
> Best regards,
> 
> Le 28 nov. 2011 à 04:55, Tim Selander a écrit :
> 
>> Also, I understand that the new LC server available on on-rev.com can serve stacks. Would it be less hassle/security risk to use a data stack, or even a big text file, as the database? We'll probably max out at 10,000 records or so... not breaking a sweat for a sql database.
> 
> --
> Pierre Sahores
> mobile : 06 03 95 77 70
> www.sahores-conseil.com
> 
> 
> 

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com