[PLUG] Small script webapps

Carlos Konstanski ckonstanski at pippiandcarlos.com
Sat Dec 12 23:04:43 UTC 2009


On Sat, 12 Dec 2009, Keith Lofstrom wrote:

> Date: Sat, 12 Dec 2009 14:21:45 -0800
> From: Keith Lofstrom <keithl at kl-ic.com>
> Reply-To: keithl at keithl.com
> To: Carlos Konstanski <ckonstanski at pippiandcarlos.com>
> Cc: keithl at keithl.com,
>     "General Linux/UNIX discussion and help;	civil and on-topic"
>     <plug at lists.pdxlinux.org>
> Subject: Small script webapps
> 
>> On Sat, 12 Dec 2009, Keith Lofstrom wrote:
> ...
>>> Many PLUG members seem to spend most of their time in GUI-land.
>>> Which is good, if all the visual metaphors are consistent and the
>>> right tools are available.   But it is much harder to automate
>>> small hacks that way - you become dependent on others who are
>>> skilled with gtk or qt and c++, who spend days to months polishing
>>> their creations with check boxes and options.
> ...
>
> On Sat, Dec 12, 2009 at 02:35:41PM -0700, Carlos Konstanski wrote:
>> I do both. But my GUI hacks are generally webapps. This is because I
>> am a web developer, and I have a convenient web container for such
>> occasions. I am interested in playing around with ncurses at some
>> point. Being a product of the 80s, I have an affinity for plain text
>> output.
>
> Good reminder!  Actually, what little "GUI" stuff I've written has
> also been webapps, simple respond-to-webform stuff for my websites.
>
> Which leads to a question:  is there an easy way to run some subset of
> webscripts locally on a machine, without the complexities of apache?
>
> Ideally, it would consist of some programs on the machine that
> respond to html requests on special ports by running small scripts
> in /usr/local/web (for example), wrapping those scripts with enough
> html stuff to talk to the browser.  The browser might have a plugin
> so that when it sees a request for a naked word "URL" it tries the
> program hanging on the local port before it looks on the rest of
> the web.
>
> As an example, I could type "bacon" into firefox, and it would go
> to port 8088 (say) and ask the program watching the port to look
> for /usr/local/web/bacon, wrap it as needed, and run it.  If there
> is no /usr/local/web/bacon or ~/web/bacon, firefox does its usual
> thing with barewords, which in my setup is do a google search for
> the word bacon.
>
> That would allow me to run local scripts, perhaps with some graphic
> content, via the local browser.  Then I could deploy the same or
> similar scripts through apache on a real website.  Democratized
> small webapps?
>
> Keith

I guess I would have to argue that apache is a fairly simple tool to
use, especially for running web utilities like the ones we are
describing here. You can almost get away with the default
configuration, if you're willing to put all your scripts into one big
DocumentRoot. There are even smaller HTTP servers, but apache isn't
all that big, and it's rock solid.

You could get your "bacon" URL scheme to work by using a local DNS
server. Just have BACON be a CNAME for the host. Then configure apache
on that host to have a vhost entry that matches "bacon". The request
will make it to the host, and apache will know what to do with it once
it arrives there.

Writing a socket listening program from scratch is more of a pain than
it is worth. It is much, much easier to use an existing, stable,
well-tested daemon. Apache is a great tool for this. Did you know that
you can run a /bin/sh script as a CGI?  Anything that is executable is
fair game. Let apache do the work of marshalling requests, and save
your efforts for the actual scripts.

Carlos



More information about the PLUG mailing list