Leightweight pure TCL web server
graeme....@gmail.com
data) web server in TCL, to join the many that already exist :)
It provides a reasonable implementation of HTTP1.1. No keep alive
(largely because it looks hard to test, especially with pipelining),
and a few other bits missing.
Documentation is comments in the code, but fairly extensive, but there
is an HTML marked up version of the code which makes both code and
documentation easier to read.
More here: http://pietersz.co.uk/software/dandelion-server
I would be very grateful for any comments on:
1) Whether it looks useful.
2) The quality of the code.
It is pretty carefully written (I have learnt a lot of HTTP recently),
but, as an amateur without any external control or guidance, it would
really help if I get some feedback to tell me if I am going the right
way or not...
Neil Madden
It looks quite nicely written to me, making good use of modern features.
But I haven't time to properly review the code in any depth. The only
obvious thing I noticed was a slightly redundant bit of code at the
start, where you do:
dict for {k v} $errors {
.... [dict get $errors $k] ...
}
Here the [dict get] isn't needed as the same info is already in $v. I'm
also slightly wary of the [encoding convertfrom utf-8] in the decode
proc -- are you sure it's correct? I would have expected the data to
already have been converted (from some encoding to Tcl's utf-8) by that
point when it was read from the channel.
-- Neil
graeme....@gmail.com
> graeme.piete...@gmail.com wrote:
> > I have written a single file of source (plus one file with mime type
> > data) web server in TCL, to join the many that already exist :)
>
> > It provides a reasonable implementation of HTTP1.1. No keep alive
> > (largely because it looks hard to test, especially with pipelining),
> > and a few other bits missing.
>
> > Documentation is comments in the code, but fairly extensive, but there
> > is an HTML marked up version of the code which makes both code and
> > documentation easier to read.
>
> > More here:http://pietersz.co.uk/software/dandelion-server
>
> > I would be very grateful for any comments on:
>
> > 1) Whether it looks useful.
> > 2) The quality of the code.
>
> > It is pretty carefully written (I have learnt a lot of HTTP recently),
> > but, as an amateur without any external control or guidance, it would
> > really help if I get some feedback to tell me if I am going the right
> > way or not...
>
> It looks quite nicely written to me, making good use of modern features.
the improvements in 8.5 while writing this.
> But I haven't time to properly review the code in any depth. The only
> obvious thing I noticed was a slightly redundant bit of code at the
> start, where you do:
>
> dict for {k v} $errors {
> .... [dict get $errors $k] ...
>
> }
Thanks. Fixed.
>
> Here the [dict get] isn't needed as the same info is already in $v. I'm
> also slightly wary of the [encoding convertfrom utf-8] in the decode
> proc -- are you sure it's correct? I would have expected the data to
> already have been converted (from some encoding to Tcl's utf-8) by that
> point when it was read from the channel.
Yes, it is correct. It does not work correctly with UTF-8 input
without it - in fact, I only got it working after asking here what I
was missing.
Of course I am assuming that POST data will be UTF-8 or ASCII, so
maybe I should change it back to what ncgi does, and leave the app
calling it do decide whether to convert it.
Thanks again for taking the time to look at it.
Graeme
bobicanprogram
The SIMPL open source project (http://www.icanprogram.com/simpl) has
been around for almost 10 years now. It promotes a very tidy Send/
Receive/Reply message passing framework similar to that first
commercialized by QNX.
SIMPL has had Tcl/Tk hooks almost from the beginning. SIMPL modules
written in Tcl/Tk can easily exchange messages with other SIMPL
modules written in C or Python.
If you want to extend your little webserver in a different direction,
we'd love for you to give it SIMPL Send/Receive/Reply
capabilities. This would allow SIMPL modules to receive messages
directly from a browser interface.
If you are interested by all means contact me offlist.
bob
SIMPL project coordinator
graeme....@gmail.com
I hope you do not mind me replying on list, but given my questions
other people might have something to add.
SIMPL looks interesting, but I am having difficulty understanding it -
there does not seem to be much documentation for the TCL library.
What exactly do you have in mind? Making it easy to write browser a
front end for existing SIMPL modules?
I was thinking of something the other way around. What about using
SIMPL to send requests from a load balancer to a cluster of TCL
webservers sitting behind it? Less overhead and faster than TCP
(right?), cross platform (unlike unix domain sockets), can use TCP if
the TCL servers are on another machine and easy to implement on the
TCL side because we already have the SIMPL library. One problem is
that I am not a good enough C programmer to do the C side of it.
Of course, I have not groked SIMPL, so this may just be a stupid
idea....
bobicanprogram
Yes improving the SIMPL documentation is always on the todo list.
The SIMPL-Tcl interface mirrors the C interface almost exactly. It
is a very tidy API with essentially only 5 functions most would
normally use:
name_attach - used to give the Tcl program a SIMPL name
name_locate - used to open a SIMPL communications channel to another
SIMPL process in same sandbox
Send - used to transmit a SIMPL message over the communications
channel previously opened
Receive - used to receive a SIMPL message
Reply - used to respond to the SIMPL sender with a message
The book Programming the SIMPL Way has lots of Tcl/Tk examples of this
API in use. Lots of sections of this book are available for viewing
on Google Books (http://www.icanprogram.com/lulu.html).
It is probably best to illustrate by example. The book sample code
is available for download at
http://www.icanprogram.com/simplBook
or
http://www.icanprogram.com/simplBook/simplBook.self.html
A while back I gave a talk about SIMPL-Tcl at a local Linux User
Group. The slides and the sample code are available online at:
http://www.icanprogram.com/hosug
In its simplest form a SIMPL enabled webserver could allow an HTML
front end to a SIMPL sender. The SIMPL book uses a Sudoku puzzle
solver as a sample project. The Sudoku solver engine is a SIMPL
receiver, written in C.
If one had a SIMPL enabled webserver it would be easy to imagine
creating a transparent browser front end to this solver engine.
Users could submit Sudoku puzzles from a browser interface. In the
SIMPL world modules written in Tcl/Tk can transparently exchange
messages with modules written in any of the other supported languages
(C, Tcl/Tk, Python).
A while back someone asked the SIMPL project about the possibility of
using SIMPL messaging to simplify his interfacing to his TCP/IP
enabled video camera. He envisioned replacing the onboard webserver
in the camera with a family of lightweight SIMPL receivers, while at
the same time retaining the transparent web interface into those
cameras.
Over the years others have queried the SIMPL project about several
other possible applications for a http interface into the world of
SIMPL. There is one SIMPL developer I know who is actively pursuing
a fast CGI interface using Python as the language. I personally
prefer Tcl/Tk over Python. I also believe that integrating SIMPL
directly into the webserver itself would yield a richer set of
application possibilities with better performance than the CGI
approach.
Your load balancing idea could also work. SIMPL uses a shared
memory method to transport messages between modules in the local
sandbox. It transparently uses TCP/IP surrogates to enable
transport of messages between modules running on different nodes. In
fact there is no code difference between a SIMPL module written for
local message exchange and a SIMPL module written for network wide
message exchange.
As for your C programming comment, SIMPL fully supports modules
written in C, Tcl/Tk or Python. You can mix and match as you see
fit. So if you prefer to code in Tcl/Tk then that will work.
If this doesn't answer your questions satisfactorily, I'd be most
happy to continue our email conversation offline. I'm also willing
to help out with demo code where I can.
bob
SIMPL project coordinator