Asynchronous Server Design
david at viral.academy
Mon Jul 20 15:40:50 CEST 2015
I have a question for any of you out there that know a thing or two about
synchronous vs asynchronous design:
- Is it worth designing a Livecode server to use asynchronous calls to
handlers rather than normal synchronous processing?
First off - the way this is going to be done will not use any io (file,
shell or internet / socket calls) - all the data is going to be in memory /
custom properties. This restricts the use case to simple sites for now -
but it suits the current purpose. This means we can use Livecode asynch
call / messaging features to the full.
The question is is there any point? Firstly, because messages come into the
server and are then immediately dispatched by the engine to event handlers
we craft. So is this all the asynchronicity needed?
Or are there some other tricks akin to the things node does if there are
long running processes. Say there is a handler:
command longRunningFibonacci someInput, someSocket
> -- do something that takes a very long time
> return a result
> end longRunningFibonacci
A browser fires off around 20 calls to the server to load a complex page,
and they all hit at once - so is there a design consideration for any long
running processes here - not just in terms of figure out a bette way t do
ti on the client, not with regard to the scripting of the server handler
Does the fact that the engine is dispatching calls means we can forget
about this - or as I think is the case should I consider dispatching /
offloading to another process this long running task, and returning
something to the browser? If so do I keep the socket open, or ???
More information about the use-livecode