[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Freecats-Dev] Now, about our HTTP server...
From: |
Henri Chorand |
Subject: |
[Freecats-Dev] Now, about our HTTP server... |
Date: |
Wed, 29 Jan 2003 01:12:34 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 |
Hi all,
A few days ago, I noted an interesting comment by Dave Simons:
> By the way (going off on a complete tangent), one of the really
> cool features of Tcl is that you can send messages between Tcl
> applications, even if they're running on different interpreters
> on different machines. For example I wrote a Tcl/Tk front end
> for an exisiting text-based Gnutella servent (sic). This
> required two event loops, one for the GUI, the other for
> catching and conditioning the output from the text interface.
> I won't go into the details of why the use of 2 loops was
> desirable, but by putting them in separate applications (I'm
> not even sure whether you can have two loops in the same
> application), everything became much tidier. The applications
> intercommunicated via messages. I don't know if this feature
> would prove useful in FreeCATS but it does no harm to know
> about it.
I'm thinking about such a setup for the interface part of the server.
Dave being, apart from Apache Tcl's David Welton, the highest-ranking
Tcl officer on this list...
So I thought we could design our server as follows:
1) Micro-HTTP server in Tcl (probably works as a loop), receives
requests sent to the server, makes calls to subroutines and returns
answers. In fact, I found somewhere that a micro-server was written with
around 250 lines of Tcl code, I believe it's worth a look.
So, this module would handle access (authentication to be further
defined, preferrably something already written & well documented).
2) A set of subroutines (all our API functions).
This is something where I seriously lack background info: it seems to me
that some tasks may be run in asynchronous mode, like context search
queries (any read-only TM access), user/admin connection management...
But should not the TM update tasks run in synchronous mode (one query at
a time with a single process managing everything that's happening in
terms of update)?
Unless the above is not "proper HTTP", to use a simple term, and we
should use "well" written routines so as to also work in asynchronous mode.
Could anybody provide a basic explanation of how a HTTP server works?
Henri
- [Freecats-Dev] Now, about our HTTP server...,
Henri Chorand <=