LiveCode Server - where to start?

Tue Jul 7 12:45:36 EDT 2015

Richard, you are always so generous with your advice and your time! Thanks, that helps a lot. I still  need to understand a lot more, but it’s a flying start.

Pasadena, eh? I was not so far from there last September, but another trip to the States will have to wait a year or two - if I haven’t dropped off my perch by then. Yes, it was a great pleasure to meet you in Malta - I did go to the last Edinburgh conf but of course it was just a step for me.

Thanks again - and I can’t help feeling I’ll be back with more questions!

Graham

> On 7 Jul 2015, at 17:39, Richard Gaskin <ambassador at fourthworld.com> wrote:
> 
> 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
> 
> _______________________________________________
> 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