server vs not server

Mike Kerner MikeKerner at roadrunner.com
Wed Jan 20 14:13:22 EST 2016


I have a pile of OS's running, here, for all sorts of reasons.  Yes, I
could, and have, deploy (and develop) on one of several linux boxes that I
have running you-name-it with whatever desktop environment is on that box.
In some cases, there are issues where some other piece of gear is OS
limited to Windoze, for example.

On Wed, Jan 20, 2016 at 12:53 PM, Richard Gaskin <ambassador at fourthworld.com
> wrote:

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



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."



More information about the use-livecode mailing list