Chrome, lchttpd and a possible Livecode socket bug?

[David Bovill]

Essentially (see below) the idea is that two functional requirements can
(somewhat counter-intuitively) be combined into one software application.
Flexible ease of use and scalable production use.

The first use is a simple minimal scriptable server that I can customise
for my own needs and run in low load situations on a LAN, and the second is
to take exactly the same code and server and scale it using multiple cheap
load balancing servers.

The one thing we don't try to do is serve large or complex HTML sites -
leave that to the existing robust multi-threaded servers. This is more of a
Node type single-threaded, role-your-won, specialist server philosophy.

Thanks for taking your time to answer - as the more heads on this the
better I think it will be. I spent yesterday refactoring André's stack,
(based largely on mchttp), and also Todd's work. I see the server much
closer to Todd's Node-like approach, but need to add some of the
input-reading loop of revHttp. I also want to add support for POST / PUT /
DELETE etc

Let's call this thing a catchy name = LiveDaemon?

On 15 July 2015 at 18:04, Richard Gaskin <ambassador at fourthworld.com> wrote:

> David Bovill wrote:
>
> > The prototype I am working on is to create a Livecode daemon/server
> > that has the follewoing functions:
> >
> >    1. Drop dead easy to set up for local use on a laptop, or to serve
> >       a LAN in a teaching / workshop scenario
> >    2. Fast and minimal REST API provider.
> >    3. Deployable behind a load balancing server
> >    4. Plays well with Node, Nginx, Apache in a load balancing
> >       production environment.
>
> In that setup, what is the relationship between the LC daemon and the
> NgineX and Node daemons?


I'm not too familiar with NgineX, but the principle is to use routing /
load-balancing to let existing servers do what they do well at scale, and
fit LiveDaemon into that Mix in flexible ways. By flexible I mean under
Livecode script control. I want to be able to go from "this works on my
Desktop - let me add it in this scaleable way to my server(s)".



> > My understanding is that it should be possible to script the
> > deployment of custom servers in an environment like Linode in a
> > few minutes - whether that be a single Livecode server or several
> > of them behind a load-balancing proxy.
>
> Linode has a good reputation, and I've also had good luck with VPSes from
> InterServer and Chunkhost.


I'll take a look at those. The requirement for me is that they expose all
their functionality via an API, so that we can script deployment in
Livecode. It is amazing to pop up a server in under a minute under script
control, shut it down again and only pay $0.007 for an hours deployment.

The interesting thing I want to explore is scripting the load-balancing /
routing in Livecode.


> I'm also interested in moving beyond using libraries and front and
> > back scripts to exploring the use of chained behaviors in this
> > architecture.
>
> Interesting.  I've used behaviors extensively for UI things, but hadn't
> considered them for server use.  What is the advantage there?


 Essentially it is the combination of avoiding pollution of a global
name-space, and secondly allowing mixin-type construction of libraries.

I have a lot of libraries open - and if I distribute them I have to name
the handlers in awkward syntax to avoid possible name-clashes - and even
then there is no guarantee. Refactoring my libraries into behaviours helps.
I can take a stack and add as many chained behaviour scripts as i want,
then use the stack and I have a custom library. That is especially useful
to take out generic handlers that are shared between several other
libraries.

For instance for LiveDaemon, I abstracted the logging code into it's own
script-only stack, and the core server code into another script-only stack.
If I want a library I set the behavior of a used stack to both behaviors
chained together. If I want the button based server architecture of Todd
and Andre - I just set the behaviors of the button.

> Finally I'm wandering about an architecture which allows you to deploy
> > standalone servers that speak to each other via (as you say) custom
> > binary protocols.
> >
> > I'm going to have a whole bunch of questions I am sure - the first
> > one is whether running a daemon on a cloud based server can be
> > achieved using LiveCode server?
>
> I can't say.  I've never tried using LC Server as a daemon, and I don't
> even use it as a CGI in production work, only for testing to help others.
>
> I use Linux standalones run facelessly with -ui for all server apps,
> mostly because it allows me to run and test everything in the IDE with
> close to zero behavioral differences over runtime.
>

OK - that sounds good. I'll try that. There used to be annoying
requirements for the server to have certain interface related libraries
installed with mc - is this good to go with the standard Ubuntu server side
set up?


> LC Server is a very good choice if you're accustomed to PHP-style
> wokflows, but even when delivering Web pages I don't normally mix much LC
> and HTML in the same file so calling the merge function explicitly is as
> good for me as LC Server's implicit merge.
>

Yes.


> For non-HTML output, such as the binary data you're describing, either the
> LC Server or desktop engines may do well with that (provided the event and
> socket handling in Server is as good as it is in the desktop engine), but
> using a standalone will allow the system to be MUCH more easily testable.


OK - but since the Livecode cgi-based server runs stacks - would it not be
possible to simply get it to run the same stacks??? I wander if it allows
you to use sockets?

One thing I noted in a test is that trying to use normal libURL calls while
serving over sockets failed - I was forced to use shell and curl.