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