Using MySQL on (headless) Linux
ambassador at fourthworld.com
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.
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.
>> On Feb 4, 2021, at 9:52 AM, Richard Gaskin via use-livecode
>> <use-livecode at lists.runrev.com <mailto:use-livecode at lists.runrev.com>>
>> 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