server vs not server

[Richard Gaskin]

Mike Kerner wrote:
 > I have a bunch of stacks that run, constantly, doing a variety of
 > things.
 > Some are even run as daemons by other processes.  So, I suppose they
 > could run in server, but I'm still unclear as to why I would choose
 > to do that.

LC Server is a great tool for mixing LiveCode scripts with HTML for 
convenient delivery of web pages.

But beyond that, the differences in terms of benefits to the developer 
between using the Server edition and running a standalone facelessly 
with the -ui flag are minimal, and often favor the standalone.

In fact I've never deployed a production system with LC Server, even on 
web sites like LiveCodeJournal.com where the entire CMS all the way down 
to the data store is entirely written in LC.  Calling the merge function 
explicitly rather then having an extended version called implicitly is 
handy but ultimately less valuable for me than having an engine that 
works identically on both desktop and server.

Most of my work these days is delivering client-server workgroup 
solutions, and LC provides a complete solution on both ends.  But by 
using a "desktop" standalone as the CGI instead of LC Server, it was a 
trivial matter to integrate the server functionality directly into my 
client development workflow, all running within the LC IDE.

Of course LC Server also provides many other conveniences for web work, 
like parsing incoming POST data, but since I've been using LC as a CGI 
since it was called "MetaCard" I already had libraries for those things 
more than a decade ago.

So for web development LC Server can be very convenient, but with a 
little extra work one can use a "desktop" standalone equally well, with 
the extra benefit of being able to develop and test directly in the IDE.

But outside of web development, if all you need is a LiveCode engine to 
run some scripts and you don't need a GUI, just call a standalone with 
-ui so the engine knows not to bother initializing GUI elements 
(launches super-fast and takes less RAM and fewer CPU cycles as it runs):

   /home/<user>/LCdaemonFolder/lc-daemon -ui

Whether I'm building a socket server on a VPS or just need some 
auxiliary processing on a separate machine so I don't tie up my 
workstation, standalones are a wonderful option that gives us nearly 
complete fidelity between development and runtime.

I generally make the standalone very slim, in which the only code is a 
startup handler that looks for a stack file in the same folder; if it 
finds the stack it runs "start using..." to bring it into play, and if 
not it reports an error and quits.

This lets me update the app by just replacing the very slender stack 
file, never touching the standalone at all until there's an engine 
upgrade I need for new things.

Extra bonus points: if you share your public SSH key with the target 
machine running your LC standalone, you can completely automate updating 
your stacks and other files very conveniently using rsync, regardless 
whether the target machine is a spare computer on your local network or 
a VPS hosted anywhere in the world.  Write in the UDE, click a button in 
a plugin stack, and - poof! - everything on your remote system is 
updated with all the smart efficiency rsync delivers.

Instructions for this are all over the Web; I particularly like the 
simplicity of this one:
<https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2>


Tip about file polling:  while we're (often rightly) conditioned to 
think of file I/O as a bottleneck, checking for the existence of a file 
is not very costly at all, not nearly as much as opening and reading a 
file.  Even on Windows it takes relatively few clock cycles, and on any 
Unix-like system like OS X or Linux the ultra-smart file caching 
mechanism makes it even faster - much faster, so that the overhead of 
polling once every few seconds or even once a second, is barely measurable.

If speed is critical you can even take that one step further if you're 
using Linux* by using the /run/shm/ directory for delivering files that 
need to be polled for.  The /run folder is a sort of RAM disk 
automatically created by the OS, so while it won't give you persistence 
between boots it'll make file I/O even breezier for those cases where 
it's a good fit, such as delivering instructions to an LC daemon without 
the complexity or security concerns of direct socket comms.


* For a faceless system why not use Linux?  It runs on nearly any 
hardware made in the last 20 years, is free in both senses of the word, 
and the biggest benefit of OS X is its UI which you'd never see anyway. 
  When any machine in my office outlives the vendor's OS support, it 
gets wiped with a Linux install where it gets a new and well supported 
life, and all the bash commands I'd used on my Mac continue to work (but 
in many cases with newer and less vulnerable components -- see the many 
web articles about why Apple ships with outdated and vulnerable versions 
of things like rsync).

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