Using MySQL on (headless) Linux

Richard Gaskin ambassador at
Tue Feb 16 03:39:17 EST 2021

Thank you, Mark, but the downside to my longish emails is that I'll need 
further guidance: which part/phrases would be of greatest interest? 
Happy to see if I can put together something to help with it.

  Richard Gaskin
  Fourth World Systems

On 2/4/21 3:33 AM, Mark Smith wrote:
> Richard, you’ve covered a lot of territory in this message most of which 
> I don’t understand since I’ve never had a need to delve into this aspect 
> if LC technology, but I’m really fascinated by the potential and would 
> love to learn more. Could this possibly be a topic for a half day (or 
> full day) workshop at the upcoming LIVECODE NYC 2022? If so, I think it 
> would be one of those topics that makes it worth the price of admission.
> Cheers
> Mark
>> On Feb 4, 2021, at 9:52 AM, Richard Gaskin via use-livecode 
>> <use-livecode at <mailto:use-livecode at>> 
>> wrote:
>> Mark Waddingham wrote:
>>> On 2021-02-03 20:07, Richard Gaskin via use-livecode wrote:
>>>>> LC Server had already been ruled out (for whatever reason) in an 
>>>>> earlier part of the thread...
>>>> That's too bad. LC Server is LiveCode build designed specifically for
>>>> command line use.
>>> Interesting - I don't remember that being what I specifically 
>>> designed it for :P
>>> LiveCode Server was *specifically designed* to be used just like PHP 
>>> - allowing you to interpolate code with HTML output for the purposes 
>>> of constructing webpages on the fly, sitting behind a web-server... 
>>> That's why it has unique syntax designed precisely for a CGI 
>>> environment, and operating in that PHP-like manner.
>>> Making it run in command-line mode as well was an obvious thing to 
>>> do, and also made up for the fact (at the time) that bare standalone 
>>> engines would not launch a stack on the command-line (as that was a 
>>> rather gaping licensing hole which was closed between v3 and v4
>>> IIRC). [ It also made it easier to test the general features of it! ]
>>> Since the advent of the community edition, however, and perhaps more 
>>> importantly script-only-stacks - standalone engines running with -ui 
>>> can be just as convenient...
>> Indeed it can.  The -ui option for running standalones was something 
>> many of us enjoyed back in the MetaCard days; AFAIK it was first 
>> implemented with v1.0 back in '92; it least it was there when I first 
>> started with MC back in '96.
>> In addition to being an option for standalones, one could even run the 
>> bare engine with -ui as well.
>> And being a command line tool that uses stdin/stdout, running the 
>> engine or a standalone with -ui also worked well as a CGI under Apache 
>> or Lightly (though in a flavor more like Perl, Python, or Ruby than PHP).
>> Your fine addition in more recent years with a special Server build to 
>> allow PHP-like co-mingling of code and content was well done and much 
>> appreciated for those who enjoy that workflow on web servers.
>> And back in '14 David Williams reminded us that the standard shebang 
>> option for running a script text file is still available, though with 
>> a slight syntactic difference from how we used to do that with MC 
>> (entry point used to be a startup message, now just bare script 
>> statements outside of a handler):
>> With all this flexibility in one lean install, for me the pros of LC 
>> Server for headless work are clear:
>> - We get the benefits of a standalone without having to make a
>>  standalone (indeed the engine can be kept up to date with a
>>  scrape-n-wget from the Downloads page, without needing to run
>>  it through the Standalone Builder on a separate GUI system).
>> - We have the same options for running it as a standalone, without
>>  needing to remember to add -ui (minor, but every little simplicity
>>  is nice).
>> - BONUS: We get the bonus option of running it aa a CGI without
>>  needing to write our own libraries for that (reading and parsing
>>  POST, writing to stdOut, handling every little detail about
>>  headers, sessions, and more).  And when we do, we can enjoy
>>  PHP-style implicit merge, mixing content and code much more
>>  conveniently than with the merge function.
>> That bonus may be irrelevant for some use cases, but probably not 
>> many. After all, a headless machine is usually not our main dev 
>> machine; it's probably being deployed to provide services for client 
>> machines. When those services are being delivered over a network we'll 
>> need a protocol, and in most cases HTTP will be a great choice, 
>> certainly the most common one. And though we can write our own HTTP 
>> daemon in LC, letting Apache do that generic work gives us better 
>> throughput, robustness, and security, with lower maintenance costs.
>> Letting Apache do what it does best lets us do what we do best: focus 
>> on the functionality unique to our application service.
>> All that said, perhaps my appreciation for your work with LC Server is 
>> indeed misplaced, and maybe it shouldn't be encouraged as the go-to 
>> choice for headless LiveCode development. :)
>> But as one who resisted using it for many years after it was released, 
>> continuing to use standalones with -ui, I must admit that the 
>> efficiencies in both execution time and my development and maintenance 
>> time eventually made me uniquely enamored of LC Server as my default 
>> choice for any headless system.
>> So if this makes me an LC Server fanboy, guilty as charged, your honor.
>> --
>> Richard Gaskin
>> Fourth World Systems

More information about the use-livecode mailing list