http://www.jwdt.com/~paysan/httpd-en.html

can any of you readily read this code?

If I remember right, a server through inetd will not be very efficient
although I could be wrong.

gavino wrote:

Of course. It's pretty straight-forward Forth. Don't expect Forth to look
like C, it's a completely different and not related language. It's like
asking a bunch of Chinese if they can read this strange language - yes, of
course they can.

With the newly improved socket.fs, it should be quite simple to implement
the server without inetd (haven't found the time yet). But on efficiency: I
used this web server for years on my memory starved 32MB laptop instead of
Apache, because it was so much faster (for local viewing of my web pages).
Gforth doesn't take long to start and to compile the application, it
doesn't take much memory, and all this offsets the potential performance
gains from Apache in this particular environment.

On Aug 16, 3:20 pm, gavino gmail.com> wrote:

I work with a guy who states he is relatively weaker in C than the
other engineers at work. He's not dumb, but he does tend to get
distracted by the details. He commented once that he admired that I...

John Passaniti gmail.com> wrote:

John Passaniti wrote:

What I want to say with this exaggeration (the "almost" is even in quotes)
is that I've already done too much for the specific thing I want to
achieve. The thing I want to achieve is in the introduction. I very clearly
specify what my goal is. If some people misunderstand that, try rereading
the introduction, and try understanding what my goal is in the "Outlook"
section (big hint: it mentions getting a http server into one screen).

And don't forget: The 90/10 rule actually should be used as guideline what
to implement: 90%% of the users of bloatware use 10%% of the functions (in
typical bloatware, that's even a common 10%%). Just implement 10%% of the
functions in a lightweight software, and these 90%% are happy.

On Sat, 16 Aug 2008 12:20:11 -0700, gavino wrote:

Welcome to Forth.

Totally depends on the process load time. Hang a Python web server
framework off inetd and you'd have an obese dog with fleas. Forth can be
much more lightweight.

FWIW, if I was doing httpd in gforth I'd write it with much smaller
words. I'm one of those 'old fart' programmers who indulge in this lame
practice of putting general and stack comments in source code, to make
words readable to those who don't necessariy eat, sleap, breathe, pee,
dream and make love in forth.

On Aug 17, 4:21 pm, Bernd Paysan wrote:

As evidenced from my criticism, I didn't have any problem
understanding your goals. I wrote that you implemented exactly what
you needed and nothing more. That's not a slight. That's a
recognition of the "simplest thing that could possibly work" mindset
that is dominate not only in Forth, but in modern development
practice. It's valid, respectable, and useful.

On Aug 16, 1:18 pm, Bernd Paysan wrote:

On Aug 17, 1:21 pm, Bernd Paysan wrote:

gavino wrote:

Static pages. There's this simple 4-line "dynamic content" package, but to
be realistic, really useful dynamic content should at least have code to
handle user logins and cookies, and that includes the refrigerator
application (data base in files and directories is completely sufficient
for many simpler tasks, but login is necessary if you want to do more than
just monitoring, e.g. adjust the temperature or whatever). My philosophy is
that you should pre-create as much "dynamic" content as possible - the
number of updates is far less than the number of read accesses.

The only excuse is when you can't predict how the dynamic content will look
like, e.g. when you randomly insert ads, or when you give access to tons of
data like web-mail interfaces or web-version control or this sort of
application, and duplicating all that data is not feasible (especially in
the web-VCS interface, where you can e.g. compare two different versions of
the same file, which is stored as compact representation in the VCS, but
has a combinatoric explosion in the web interface).