Thoughts on Livecode Server

Thu Jan 24 04:50:46 EST 2019

Thanks for the time replying Richard!

Let me outline where a bit the context of my questions. It's not about the
basics of how to rn a server / cgi. It's about the relatively long term
direction of server technology and Livecode server. I'm interested to
experiment with Livecode server again as i feel there are soe promising
recent advances which make the technology interesting to develop for long
term.

I'm very familiar with Pierre's work. I think th eIPC / socket based
approach with dockers and cluster management behind a reverse proxy is the
best way to go / standard way to go right now for achieving a scaleable
server deployment with Livecode in the mix, I'd use Livecode for doing
things that I can do quickly in that language and use the more standard
(probably javascript based) web servers for handling standard web traffic.
I'd probably use Livecode for creating authoring environments. I want to be
able to use standard javascript libraries where they are available and not
have to code every library myself in Livecode.

So the main requirement - I think - is for practical Javascript
interoperability on the server side. Ideally we could just "do javascript"
in the server environment, and load whatever node modules we want to do
their thing in Javascript = Livecode server extensions written in
Javascript.

Based on your feedback that we can use "the template xxx" or a stack with a
widget and execute these in the server environment - the thought is that
"do as javascript in browser" would do the job here... this might be a
pragmatic way to develop server side logic in a mix of Javascript and
Livescript without the need for the whole cluster-docker-sockets thing.

The other strategy is basically a web assembly (WASM) take on the same
issue. WASM promises (AFAIK) a medium term strategy not just for creating
elements in the browser - but also for creating applications based on
gluing together various wasm components that could be authored in different
environments / languages.

Related to this approach could be a stop-gap experiment where we create a
javascript server in node / vue - that loads a Livecode engine and modules
based on emscripten export. Again we get a javascript server and access to
the large set of open source modules available with (hopefully?)
bidirectional communication with Javascript.

>From my perspective I'm looking to develop some slow applications over a
3-5 year timescale - from that perspective a LAMP / cgi style solution
looks like it might be a question of running an emulator :) I also need a
positive path / argument for investing more in Livecode long term - so
having a clearer picture about where the whole open language / emscripten /
wasm / server strategy is going would give me a warm feeling inside. It's
also kind of interesting :)

But I'm sure there are people here that know much more than I do about
these issues. Really happy to have feedback - negative or positive /
pointers on things to read / learn!

On Wed, 23 Jan 2019 at 19:18, Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
>   ____________________________________________________________________
>   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
>