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