LiveNode Server

[Richard Gaskin]

David Bovill wrote:

 > OK. A few questions... I'll post them as assertions to aid clarity.

Personally I find it clearer to read questions as questions, but with 
that explanation I can work with this:

 >   1. Livecode messaging is fully asynchronous. Not semi-async.

What is "semi-asynchronous" in the context of LC?

There is a distinction between "asynchronous" and "non-blocking" that 
I'm not entirely clear on, so I'll use "non-blocking" for now:

Socket I/O messaging can be non-blocking when the "with <message>" 
option is used, e.g.:

    accept connections on port 8888 with message "GotConnection"

But this is of limited value within a single LC instance, since doing 
anything with that message is likely going to involve blocking code 
(e.g., reading a file or accessing a database, doing something with that 
data, and then returning it).

So messages will keep coming in, but they'll queue up.  This may be fine 
for light loads, but when expecting multiple simultaneous connections it 
would be ideal to handle the tasks more independently.

Many programs do this with threading, but we don't have threading in LC.

Instead of multithreading we can use multiprocessing, having multiple 
instances of LC apps each working on a separate task.

The challenge is that to hand off a socket request to a child process 
entirely would require us to have some way of handing over the socket 
connection itself.  I believe fork allows this, but I know of no way to 
launch new instances of an LC app in a way that will hand over the 
socket connection to them.

In lieu of being able to fork, two options I know of are the ones I 
noted earlier; others may be possible as well, but these seem common 
enough to be reasonable starting points:
<http://lists.runrev.com/pipermail/use-livecode/2015-April/213208.html>



 >   2. There are a bunch of functions that are currently synchronous in
 > LiveCode that make it difficult to create asynchronous code - such as
 > certain network call like POST.

Yes, as above.


 >   3. Livecode does not have closures = passing anonymous callbacks as
 > params to functions so they can be executed later

Not per se, but as you note:

 >   4. But we can easily call / dispatch calls to functions by passing
 > names around and we can limit scope by using private handlers or
 > libraries.
 >
 > Here is an article about why you should not use anonymous callbacks
 > that seems interesting in the context of readabiity and literate
 > programming languages:
 >
 >   * Avoiding anonymous JavaScript functions
 > http://toddmotto.com/avoiding-anonymous-javascript-functions/

Good find.  While most of that is very JS-specific, the 
readability/complexity argument applies in LC well.  As a general rule, 
I feel that "do" is a last resort when all more direct means of 
accomplishing something have been exhausted, and even "dispatch", 
"send", and "value" can have similar impact in terms of 
debugging/maintenance.

I almost never use "do" anywhere, and on servers I limit use of the 
others for another reason not mentioned in the article, security: since 
they execute arbitrary code by design, "do", "dispatch", "send" and 
"value" can potentially be sources of injection when used on any part of 
incoming data.

I use "dispatch" in one place in my server framework, but only after 
checking an incoming command argument against a list of known one-word 
commands; any request missing a command parameter, or having one not 
found on that list, returns an "invalid command" error message.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com