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

Tim Selander selander at tkf.att.ne.jp
Mon Nov 28 21:43:16 EST 2011


Hi Pierre,

It took me a couple readings to follow your email (I'm a newbie!) 
but I think I get it... especially the point about not using a 
flat database, but letting the various parts of the system work 
in parallel. I hadn't thought about the performance hit if there 
are many, many users (though I don't think we will be that popular!)

I have installed revigniter and am working through the documentation.

Thanks,

Tim

On 11/28/11 7:47 PM, Pierre Sahores wrote:
> 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
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>





More information about the use-livecode mailing list