LiveNode Server

Andrew Kluthe andrew at ctech.me
Tue Apr 7 18:44:46 EDT 2015


I'm not using LC server side much so I can't say for sure there in
reference to this thread and the things we've been discussing. I think the
direction livecode is going and the state that it is/was (I still use 5.5
for a lot of things) in to be great.

If we can get as many of the blocking bits down to a minimum as possible
(specifically the url libraries), I think it would be perfect. The thing
that peeved me most is that most of my DB work is not done by directly
connecting to the database but some sort of api layer. Usually my LC apps
are just clients for these apis (often built in Node or python if they were
made in-house). I like the flexibility this gives me. They post some JSON
and get a JSON payload back. If the payload is large, I've had to do things
like use curl and some other things to make up for the built-in super
convenient internet library just sitting locking the application while it
waits to return. I've converted entire applications out of LC into other
technology stacks just because of the kludge needed for this one thing. I'd
love to be able to stream this stuff in a little bit at a time as well. I
can get some desired results with regular GET request using load url with a
callback but it doesn't help when I have to post a more complex query. This
happens in my .NET apps as well, but I use the parallel task libraries .NET
has to get around the UI lockups. I've been spoiled on some of visual
studio's tooling features in the meantime too :P (intellisense, jump to
definitions, some other things that i think will come to LC in time).

I also have a node-webkit (now nw.js) application that I think would be
perfectly suited to be done in livecode once things stabilize a bit (this
has already started to happen) with the newer builds using Chrome Embedded
Framework. I needed something with all the fine tuned styling I could get
from web app we already have but running as a standalone against SQLite DB.
We did this to reuse the same visual cues and javascript libraries that we
use on the web version. We wanted a copy of the web application that could
run completely without the internet. I think with just a bit of time, I
could have used LC to do this comfortably.

The short answer? An url library that can read a file off disk
asynchronously (I think this can be done now using some of the other ways
of doing disk access in LC, but it would be nice if the url("binfile:") bit
did the same thing) and an url library that can return the response of a
POST asynchronously (preferably returning chunks as they come in).

The widgets architecture sets itself up to solve all of my other potential
wants/needs, maybe even this one.

On Tue, Apr 7, 2015 at 4:19 PM Richard Gaskin <ambassador at fourthworld.com>
wrote:

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



More information about the use-livecode mailing list