This is an interesting thread. Let me add a few comments:
The CGI / FastCGI thing is a red herring. CGI is slow and so is FastCGI.
:)
Slighter faster options (e.g. for things like PHP and Python) implement
the language runtime via a plugin module to the web server.
However, things like Node.js
Yes - thanks for the input Mark.
How about having Livecode as a Node extension that we could install with
NPM? Is that not a much easier first step? I still would like to get to the
bottom of not being fork able means?
It would be fantastic to get add Live code to a Node server with a couple
of
Mark Wilcox wrote:
This is an interesting thread.
Indeed it is. Thanks for your informative comments.
Jim Lambert
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
On 14 Apr 2015, at 18:17, David Bovill david@viral.academy wrote:
Yes - thanks for the input Mark.
How about having Livecode as a Node extension that we could install with
NPM? Is that not a much easier first step? I still would like to get to the
bottom of not being fork able means?
Thanks for this Andrew - I learned a lot. I spend a lot of time passing
messages around Livecode objects with a view to making them standalone code
chunks. Debugging works pretty well - but there was a need for a library
and a graphing mechanism - design pattern style. This all adds overhead I
Yes I second that - async file and network I/O. And full REST support -
PATCH I think is not supported - or is that documented?
On 7 April 2015 at 23:44, Andrew Kluthe and...@ctech.me wrote:
I'm not using LC server side much so I can't say for sure there in
reference to this thread and the
To clarify just a little bit further. The code and objects weren't holding
onto memory, the variables used in that code were due to weird scoping. Big
chunks of db results, etc that persist after I've already done my business
with them and tried to move on.
If I can recommend a book on
I haven't had many problems with livecode chewing up memory and not letting
it go (unless I've done something obvious like stash it someplace where I
would expect it to persist). I think JS in general is prone to memory leaks
just because of how much of it was designed around the use of global
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
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
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
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
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
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
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
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
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
--
Richard Gaskin
Fourth World Systems
___
use-livecode
The question is can you create in Livecode an aynchronous event-drive
architecture? Livecode is built after all around an event loop, and through
commands like dispatch, send in time, and wait with messages, it is
possible to create asynchronous call back mechanisms - so why can we not
create a
GMTA: the folder where I keep my experimental server stacks is named
LiveNode. :)
Good stuff here, a very useful and practical pursuit, IMO, in a world
where one of the largest MMOs is also written in a high-level scripting
language (EVE Online, in Python) so we know it's more than possible
On 1 April 2015 at 16:55, Richard Gaskin ambassa...@fourthworld.com wrote:
David Bovill wrote:
The question is can you create in Livecode an aynchronous event-drive
architecture?
..
With socket I/O apparently handled asynchronously when the with
message option is used, this is a very
20 matches
Mail list logo
