David Bovill wrote:
> Does anyone have any thoughts on where Livecode server should go / is
> going?
So far it goes wherever I take it, so I haven't given much thought
beyond one enhancement request for init optimization (useful for CGI,
will make no difference for any use as a persistent process):
https://quality.livecode.com/show_bug.cgi?id=14115
> *Full power of Livecode?*
> My first question is what are the actual limits of what you can do on
> the server, as compared with the desktop version? I haven't pushed
> this to the limit so maybe yo have?
LC Server is designed to run under CGI. As with any other CGI, anything
you can do in launch-run-reply-quit command-line scenario will work
whether it's local or on a server.
> For instance if I want to integrate Javascript / node.js code into my
> server, can I use the built in two way communication between
> Javascript and Livecode?
I haven't used LC Server for persistent processes, only CGI. I have used
standalones for that, however (run with the -ui flag).
Pierre Sahores has done extensive benchmarking on using LC behind a
reverse proxy (NGineX IIRC?), and I did some tests in a related thread
using standalones as HTTP daemons directly.
I don't have enough familiarity with Node.js configuration to have an
opinion about integrating with that specifically, but Pierre might.
Most folks seem content with CGI use.
> This also leads on to the more general question about the headless
> Livecode environment of the server - are then any limits to script
> that does stuff like create a stack, add a browser element to the
> stack
A browser is a GUI element. What would its role be in the server
environment?
If you need to make HTTP requests you can do that far more efficiently
directly in LC, without encumbering it with an entire separate complex
browser app embedded in a GUI widget.
> set behaviors
Common features like frontscripts, backscripts, libraries, and behaviors
all work whether running GUI or CLUI.
> communicate with the newly created stack
In the same process, as easy as with GUI. Across processes with sockets
or pipes, or polling in /run/shm/ or other useful location.
> (and hence Javascript
Node-specific stuff is outside my current experience, but given that LC
supports the most commonly used forms of IPC I can't imagine it couldn't
be integrated in one way or another.
> destroy the stack and return a result to the browser?
As CGI no need to destroy anything, since everything in the process goes
away after the reply is delivered to Apache or whatever else calls it.
> I'll be testing this soon, but are there limits to this approach
> (apart form speed)?
Speed is a concern in CGI environments, where the entire runtime life
cycle from launch to quit happens with each request; each request spawns
a new process, so every millisecond counts.
CGI keeps things discrete and easy to work with (which is how we got the
"C" in "CGI" <g>), but lazy or complex programming on a sufficiently
buzy server can create bottlenecks with CPU time and/or RAM.
But that's not an LC thang, that's just how CGI works. Comparing some
custom scripts to popular frameworks like Drupal shows LC is quite lean
and performant by comparison (averaging 1/3 CPU time and 1/5 RAM across
the few scenarios I've benchmarked).
It's an unfair comparison, given the scope of what Drupal does, but was
enough to encourage me to continue pursuing custom solutions in LC, as I
can write things from scratch more quickly in LC than I can figure out
how to move from Drupal 7 to Drupal 8. ;)
Many get hung up on the "But does it scale?" question, but Guy Kawasaki
and others remind us how many startups fail because they overspent on
scaling for a market they never grew into because they'd spent all their
money prematurely on scaling. :)
Look at the number of even reasonably popular sites running through
Wordpress/PHP on a shared host. Scaling is overrated for many projects
that don't have significant marketing budgets to warrant accommodating
such traffic loads.
> *Emscripten export?*
> How about using the exported javascript in the server? Could we have a
> node.js based server which server-side uses the big fat Livecode
> javascript engine, and exported Livecode HTML5 exported stacks as
> server side code?
The main benefit of the HTML export is to provide a GUI for browser
clients. I can't think of any advantage in using an interpreted version
of the engine on a server when a machine-code-compiled version is available.
> *Livecode Docker behind reverse proxy*
> This is sort of the default I would say in moving on from Nginx or
> Apache based hosting of Livecode server. Does anyone have any plans /
> experience of doing this?
I don't have the URLs handy at the moment, but Pierre's benchmarks
posted here a couple years ago were easy enough to find last time I
searched for them. He doesn't post here often, so anything from him is
probably relevant to your interests.
In short:
LC is a quite capable server scripting language. Just about anything
you can do with Python, Perl, bash, PHP, etc. can be done in LC. In
some cases it may be faster, in others slower, but in most cases far
quicker to develop with.
Given the nearly infinite range of things that can conceivably be done
with a server scripting language, perhaps the more actionable subset is:
What do you want to build with it?
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
