server vs not server
ambassador at fourthworld.com
Wed Jan 20 12:53:52 EST 2016
Mike Kerner wrote:
> I have a bunch of stacks that run, constantly, doing a variety of
> 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):
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:
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).
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the Use-livecode