SSL with HTTPD Library?

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > On 11/1/18 5:02 PM, Stephen MacLean via use-livecode wrote:
 >> LC server, can do it, but also suffers, from what I’ve read in my
 >> research, a speed penalty from CGI implementation vs direct sockets,
 >> etc.
 >
 > Well that "speed penality" is theoretical. Our web site
 >
 > https://www.himalayanacademy.com
 >
 > uses Livacode server, and for all "gorilla dust" about LC's one
 > thread, open multiple CGIs, and how it is "old fashioned"

In addition to Andre's comments earlier this morning, there is another, 
perhaps more fundamental, difference between your setup and lcHTTPd:

You're still using Apache for most of the heavy lifting.


Consider the two setups, each with requests for different media types:

LC Server with .lc files:
Internet -> Apache -> LC Server

LC Server with images/CSS/everything that isn't .lc:
Internet -> Apache

lcHTTPd with LC scripts:
Internet -> LC

lcHTTPd with images/CSS/everything that isn't LC:
Internet -> LC


With LC Server, Apache handles all socket I/O and most file I/O. Indeed, 
it's handling ALL file I/O for most media types, except the relatively 
small subset of requests for .lc files where it still handles the 
reading of the requested .lc script but from there any further file I/O 
is of course up to your script.

With lcHTTPd, it must handle everything: all socket and file I/O, in 
addition to whatever your script needs to do.


In short:

LC Server is a CGI that works in conjunction with dedicated HTTPd 
software like Apache.

lcHTTPd does what LC Server does AND ALSO attempts to replace the role 
of Apache for managing I/O and serving static files.


LC is a great language, and as Node.js and NGinX show us, being 
single-threaded need not necessarily be a drawback.

But Apache, Node.js, and NGinX are written in languages compiled to 
machine code, and by large teams focused on honing the engine for the 
one specific set of tasks an HTTP broker needs to accomplish.

A scripted solution in a more general purpose tool like LC is unlikely 
to compete favorably.

There is a role for custom HTTP handling, but with so many great tools 
available that are specialized for that task the use cases where 
choosing LC for that may be optimal are few.

The HTTPd lib included with LC is designed for one good use case: local 
testing.

But for remote servers that need to handle public loads, better to do 
what you're doing:  use Apache (or other dedicated HTTP broker) to 
handle the I/O, and use LC for the dynamic application-specific stuff 
where LC really shines.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com