LiveNode Server

[Richard Gaskin]

Andrew Kluthe wrote:

>>>1. Livecode messaging is fully asynchronous. Not semi-async.
>
> Right, when I said semi-async I was referring to the single threadedness of
> livecode (which node shares) along with all the baked into livecode stuff
> that blocks up messages currently: accessing a large file on disk, posting
> some information to a web service with a large json payload being returned.
> It's async, with some pretty hard to work around exceptions (url library
> specifically has been the primary source of past frustration in this way).
>
>>>3. Livecode does not have closures = passing anonymous callbacks as
> params to functions so they can be executed later
>
> As for anonymous callbacks, I totally agree. Most early Node development
> had to overcome the callback hell that these patterns introduce. However,
> almost all of the nodejs projects and libraries I've worked with leveraged
> them heavily or exclusively. Promsies seem to have become the standard way
> of dealing with the callback hell that node was so famous for for a long
> time. Why does node use anonymous functions over the method you linked to
> in the article? Anonymous functions are marked for garbage collection
> immediately after being returned. All other functions at the global scope
> run the risk of needlessly using memory after they run. I've gotten into
> some hairy situations with memory management with these kinds of named
> callbacks (specifically for database access and return of lots of results
> when not scoped correctly).
>
> Passing a function (not just a name of a function to be used with a send or
> a dispatch later on) as a parameter even in your article still demonstrates
> something LC just can't do currently. In the article he's still using
> closures, it's just got a name instead of being anonymous. It's still a
> closure. LC has ways to accomplish similar things by passing names of
> functions and using dispatch, but I think it's not exactly the same.
> Closures are part of the reason node.js works the way it does and closures
> are one of the pirmary reasons javascript was chosen for node. It's
> certainly possible to do async without them, but closures are what makes it
> easy and kind of a fundamental principle to working in node.js.
>
>>>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.
>
> Sure, there is nothing STOPPING us from implementing named callbacks in the
> current fashion or passing the named callback references dynamically as you
> and I mentioned, but from experience trying it this way I feel like it
> makes maintaining large projects built this way a lot more difficult. To
> the point where I ended up completely redoing most of the livecode stuff
> I've written in this way early on because it was getting to be a nightmare
> to maintain a completely separate callback functions rather than the sort
> of nested structure you get in node with callbacks. It takes a lot of
> discipline in placement and grouping of the code that is related in this
> way to come back later and make sense of it. In summary: it can be done,
> but that doesn't mean that it SHOULD be done.
>
> Kind of a weird long post there. Sorry for the length and probable
> repetition of my points.

Not at all - good stuff.

What would you say would be the minimum we'd need to add to the LC 
engine to make it suitable for the sort of work you do?

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