LiveCode Server - where to start?

Richard Gaskin ambassador at fourthworld.com
Tue Jul 7 17:39:18 CEST 2015


Graham Samuel wrote:

 > Although my experience of LiveCode scripting and the production of
 > standalones is pretty extensive, I have never used any manifestation
 > of LiveCode Server, but now I want to back a web site with in effect
 > some LiveCode functionality and to communicate with users of the site
 > (for example respond to a form a user may have filled in by emailing
 > the user with derived data, while somehow retaining the info the user
 > put into the form - I am hoping against hope that this doesn’t mean
 > using a database as I don’t know anything about those either).
 >
 > The learning problem seems to me that this is a moving target in that
 > quite big changes have been made to this incarnation of LiveCode over
 > the years. Looking at the LC web site, the variety of dates of the
 > tutorial info about this is quite worrying

Ignore the dates - Common Gateway Interface (CGI) is a truly common 
convention that hasn't changed in a long time, so any tutorial will 
likely be as useful today as the day it was written. Whether using Perl, 
Python, PHP, LiveCode, or anything else as a CGI, the basic setup is 
essentially the same.

The only weakness I've seen with the tutorials I've come across is that 
they do a good job with the "what", but don't spend enough time on the 
"why".  The "why" can be important because server configurations vary, 
but if you understand how the pieces fit together you can figure out 
just about anything.

A brief orientation to get you started:

A Web server is just an app that listens on port 80, and when it gets a 
request for a resource it interprets the request and returns the 
requested data.  Most commonly this app will be Apache (though there are 
other good ones as well).

Most requests are for files, so most of a Web server's work is really 
just as a glorified file server.

But serving static files isn't very interesting, so Apache and most 
others support CGI, which allows any app that can be run from the 
command line to be used as an augmentation to the Web server for any 
special processing you like.

The key is to let Apache know that it should use your app for some 
requests, and the method you'll use to let Apache know will differ 
depending on whether you control the server or are just renting a single 
account there.

For dedicated servers and VPSes, you can specify CGI settings in the 
Apache config file.  That can be safely skipped for newcomers, because 
if you know enough to harden and maintain a server you can probably 
figure out how to configure CGI.

For shared hosting accounts (the kind most of the readers here use 
because they're quite adequate for many sites and are very cheap) you 
won't be able to modify the server config directly, since that would 
alter Apache's behavior for all users on the machine.  So instead, 
Apache includes a mechanism for communicating settings info for a single 
Web site, using a file named .htaccess.

The meat of the .htaccess instructions boils down to two things: letting 
Apache know that you're adding a special handler for a given file type, 
and where to find the app that will take action when that file type is 
encountered:

     AddHandler livecode-script .lc
     Action livecode-script /cgi-bin/livecode-server

In that example "livecode-script" is just an arbitrary label, used in 
the first line to identify that special handling is needed for files 
ending in .lc, and the second line defines the action to be taken as 
launching the LiveCode Server executable.

Once set up, Apache will get the request, launch LC Server and hand the 
request off to it, where you can process the request however you like 
and hand the data back to Apache before closing, where Apache can then 
send the data back to the client.

That the entire runtime life cycle takes place during each request seems 
like it should be prohibitively time consuming, that's because we're 
used to running LC on our desktops where its boot time is mostly spent 
on GUI stuff.  When run from the command line without a GUI LC launches 
almost instantly, and consumes very little RAM (about 1.5 MBs for simple 
scripts).


Hopefully that brief orientation will help you use this tutorial with 
confidence:
<http://lessons.runrev.com/m/4070/l/36655-how-do-i-install-livecode-server-with-apache-via-htaccess>

Please feel free to write back if any of that setup doesn't work as you 
expected.

Even better, if you're passing through Pasadena I have a standing 
invitation for anyone attending our LiveCode User Group meetings:  bring 
a laptop with FTP access to your site and I'll stay after the meeting to 
install LC Server for you.   I always enjoy your company; it's been a 
long time since Malta.


 > - there doesn’t seem to me to be a modern (i.e less than a year old)
 > tutorial about how to set up a server that runs LC stacks, plus an
 > explanation of what can and can’t be done after the install has
 > happened.

LC Server is very flexible, and in recent versions can even be used to 
generate custom images.  It may be simpler to turn the question around, 
so instead of asking what it can't do, tell us what you'd like to do.


 > Also I sense that On-Rev (I have access) is the simplest way of doing
 > this as a lot of stuff is pre-installed, but if I have server space
 > elsewhere (I do) what I have to do to get a robust implementation?

Hostm.com also provides LC Server preinstalled, but the setup is a 
one-time thing that takes only a couple minutes once you get the hang of 
it so just about any hosting company will do.  I use Dreamhost and 
InterServer, and will soon be adding another to the mix.  LC Server 
works well on both, and others here have successfully installed it on 
HostGator, JaguarPC, TierraNet, Bluehost, DigitalOcean, and more.

The only thing I would suggest when looking for a host is that they 
provide SSH support.  TierraNet doesn't, and I no longer use them for 
that reason, but I believe the others I noted here do, as do most these 
days.

For many tasks (uploading files, setting permissions, etc.) FTP will get 
the job done easily enough.  But sometimes it's invaluable to be able to 
log into the machine directly to do things FTP doesn't handle, like kill 
a runaway process because you forgot to close a repeat, or measure 
performance, or monitor memory usage, etc.  With secure shell access 
it's almost like having the machine on your desk, but without it trying 
to manage a server can be very frustrating and mystifying.

-- 
  Richard Gaskin
  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 mailing list