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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
