LiveNode Server

[David Bovill]

OK. A few questions... I'll post them as assertions to aid clarity. There
may well be mistakes - so please let me an others know if there is anything
wrong below:

  1. Livecode messaging is fully asynchronous. Not semi-async.
  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.
  3. Livecode does not have closures = passing anonymous callbacks as
params to functions so they can be executed later
  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/

@Andrew thanks for your feedback, but as I,ve not used closures in real
work I can't see how the lack f them stops us creating an async event
driven callback model for a server?

On Monday, April 6, 2015, Andrew Kluthe <andrew at ctech.me> wrote:

> I think the real missing piece in making LC work like node's event loop
> would be anonymous callback functions that can be treated like other
> variables. We can do semi- async stuff using messages in LC but you'd have
> to either name separate callback functions or dynamically pass the names of
> separately defined callback functions. We've got no way to pass an
> anonymous function as a param to something like you can with js.
>
> On Sun, Apr 5, 2015, 10:21 AM Richard Gaskin <ambassador at fourthworld.com
> <javascript:;>>
> wrote:
>
> > David Bovill wrote:
> >
> >  > On 5 April 2015 at 05:01, Richard Gaskin wrote:
> >  >
> >  >> David Bovill wrote:
> >  >> > I am not quite sure what not being forkable is here - can you
> >  >> > explain.
> >  >>
> >  >> Not as well as Andre:
> >  >>
> > <http://lists.runrev.com/pipermail/use-livecode/2009-January/119437.html
> >
> >
> >
> >  > Ok - so the key sentance there is - "We can't fork in revolution".
> >  > So what does that mean? What is so special about Livecode that
> >  > it can't do this?
> >  > It's not multi-threading - it's something.... ?
> >  >
> >  > My thinking is that what we need is to be able to have some existing
> >  > monitoring service keep a pool of LiveNode servers up and running -
> >  > in a way in which you can configure the number of servers you need.
> >  > Then you need a Node load balancing server / broker thing passing off
> >  > messages asynchronously to a LiveNode server and immediately
> >  > returning control to the user. only when all the LiveNode servers
> >  > were used up - would a cue kick into action?
> >  >
> >  > This is all standard server / inter-application messaging stuff no?
> >  > What prevents us doing that in Livecode?
> >
> > As you read in Andre's post I linked to, that's more or less what he
> > proposes as an alternative to FastCGI.
> >
> > If one is willing to put the time into assembling such a
> > multi-processing pool, the downsides relative to having forking appear
> > to be somewhat minor, not likely the sort of thing we'd run into south
> > of the C10k problem.
> >
> > What have you run into in trying this that isn't working?
> >
> > --
> >   Richard Gaskin
> >   Fourth World Systems
> >   Software Design and Development for Desktop, Mobile, and Web
> >   ____________________________________________________________
> >   Ambassador at FourthWorld.com        http://www.FourthWorld.com
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com <javascript:;>
> > 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 at lists.runrev.com <javascript:;>
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>