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@lists.runrev.com <mailto:use-livecode@lists.runrev.com>>
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):
https://livecode.com/a-livecode-shell/
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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
