revHHTP

[David Bovill]

That sounds very interesting Todd - I worked on a few LiveCode based
servers as well, and have a project that I would like to begin exploring
that would use the approach you are talking about - would love to know
more? is it an open source project - would you like any help working on it?
ᐧ

On 3 November 2014 15:37, Todd Geist <todd at geistinteractive.com> wrote:

> Thanks Richard.
>
> Yeah I wouldn't use it as public facing web server.  Although as node.js
> points out you can be a fantastic WebServer and be still be single
> threaded. But node has the advantage of having a non blocking event loop
> which turns out to solve the first big performance bottleneck, without
> having to be multi-threaded.
>
> I am interested in two things.  One, a way to make APIs for inter app and
> inter process communication.  And two, a way to build the UI for desktop
> LiveCode apps with HTML5, CSS, and JS.
>
> In my current project, I have a node.js app running in its own thread as a
> separate process, wrapped in side a LiveCode app. LiveCode provides the UI,
> and it is self updating etc.  Now that we have a nice chrome browser
> object, I could build the UI or parts of the UI in HTML, but for now the
> LiveCode UI is fine.
>
> What I needed was a way for the Node application to take to my LiveCode
> wrapper app.  This little mchttp.mc should be perfect for that.
>
> Todd
>
>
>
>
>
>
> On Sun, Nov 2, 2014 at 8:55 AM, Richard Gaskin <ambassador at fourthworld.com
> >
> wrote:
>
> > Todd Geist wrote:
> > > I am looking for a copy of the http server written in LiveCode.
> > > it was called revHTTP, and before that it was mcHTTP
> > >
> > > anyone have a copy?
> >
> > There have been a few floating around over the years.  The first was made
> > by Dr. Raney himself as a way of demonstrating robust socket
> > communications, posted at metacard.com as mchttd.mc back before the turn
> > of the century.
> >
> > Fun as it was when it first came out, over time browsers have become more
> > strict in what they expect in HTTP headers, so that original stack no
> > longer works as-is.
> >
> > Several years ago Andre Garzia wrote a much-expanded version of that,
> > which may be the one you're referring to.  If it's still around it may be
> > at his site, but I don't believe it's maintained any longer, and Andre
> > recommends using Apache and NginX for serious development.
> >
> > Given that LiveCode doesn't yet support threading, I generally agree with
> > Andre:  Apache does a good job of juggling multiple simultaneous requests
> > by spawning new instances of itself, and spawning new instances of any
> CGIs
> > it may use, like LiveCode Server.  This sort of parallelism through
> > multi-processing is important in a production environment where
> > simultaneous requests are inevitable and cannot afford to be queued.
> >
> > However, not every useful environment is for production of
> > publicly-accessible works. :)
> >
> > I have a VPS and a local server I use only for distributed processing and
> > exploratory development, and along with other tools (I may be able to
> share
> > my LiveHive project within a few weeks; more on that later), while most
> of
> > my communications with those machines is through SSH (sharing keys opens
> up
> > so many interesting LiveCode opportunities with unusually strong
> security)
> > I've sometimes found it handy to have an HTTP interface available on
> those
> > systems for private purposes where I or one of my automated systems are
> the
> > only users.
> >
> > In those cases. mchttpd.mc would be useful if only it output proper
> > headers.  So with Andre's permission I backported his header function to
> > mchttpd.mc, and have posted it to my site under a new name to
> distinguish
> > the revision:
> > <http://www.fourthworld.net/lc/mchttpd-4W.zip>
> >
> > You're welcome to use it, modify it, and share it.  I've discussed the
> > revised version with Dr. Raney and at his request it's available under
> MIT
> > license.
> >
> > Since LiveCode is single-threaded, the range of applicable use-cases as a
> > socket daemon is limited.  It will never bee Apache, and Apache is so
> > useful and flexible, and has such a vast supporting ecosystem of learning
> > materials and extensions, it's rare that we truly need anything else.
> >
> > Moreover, LiveCode Server as a CGI under Apache is a great way to get the
> > best of what each brings to the table.  Multi-processing may carry a bit
> > more overhead than multi-threading but not as much as one might think,
> and
> > is so absolutely discrete that it's much easier to code for, and in some
> > contexts more secure.
> >
> > In fact, the overhead with LC is roughly on par in my testing with
> similar
> > use of PHP, Python, or other scripting engines.  And given that we can so
> > easily make purpose-built stuff I find many instances where LiveCode
> > Server-based solutions are more scalable than similar but much more
> > generalized (hence larger) PHP-based systems like Drupal or Joomla.
> >
> > All that said, you have an adventurous mind and there's no telling what
> > you're up to. :)  The updated mchttpd may be a good fit.  I'd be
> interested
> > in hearing what you wind up doing with it.
> >
> > --
> >  Richard Gaskin
> >  Fourth World Systems
> >  Software Design and Development for the Desktop, Mobile, and the Web
> >  ____________________________________________________________________
> >  Ambassador at FourthWorld.com                http://www.FourthWorld.com
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> Todd Geist
>
>
> (800) 935-6068
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>