Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 12 Jul 2001 13:13:53 +0200
From: Luke Kenneth Casson Leighton <lkcl@samba-tng.org>
To: Sander Striker <striker@apache.org>
Cc: apr dev <dev@apr.apache.org>
Subject: Re: lib/apr_signal.c
Message-ID: <20010712131353.U29497@angua.rince.de>
Mail-Followup-To: Sander Striker <striker@apache.org>,
	apr dev <dev@apr.apache.org>
References: <20010712111935.H29497@angua.rince.de>
 <JLEGKKNELMHCJPNMOKHOKEAFEDAA.striker@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <JLEGKKNELMHCJPNMOKHOKEAFEDAA.striker@apache.org>;
 from striker@apache.org on Thu, Jul 12, 2001 at 12:47:13PM +0200

On Thu, Jul 12, 2001 at 12:47:13PM +0200, Sander Striker wrote:
> [...]
> > what i suspect is happening in subversion [correct me if i'm
> > wrong, here!] is that they are writing their own server-code.
> 
> You're wrong :)

wha-heeey :)  i like being wrong :)

> subversion is going to use httpd with mod_dav as the server :)

...  *enthusiastic*... omigud, i'm 25% way through mod_dav.c when
i looked at the LOC good _grief_.  okay, that's irrelevent.

i get the idea.

> Wondering what the framework like socketserver.py looks like.
> Summary?
 
SocketServer.py is basically three sets of classes [with
specialisations of each] that you then 'mix' together to
get the required combination for your server.

set one:

BaseServer.  specialisations: TCPServer and UDPServer
                              [i wrote a SQLTableReadingServer
                               where the 'request' is the data
                               _read_ from a queueing-table!]

Mixin.  specialisations: ForkingMixIn and ThreadingMixIn.
                         [on the TODO list is a single-process
                          Mixin that keeps a list of all connections
                          *itself* and has to deal with them one-by-one
                          with all the associated blocking and select
                          problems etc. on a series of file descriptors]

Handlers.  basically this allows you to 'Do' things to a
request.  there are some pre-defined UDP and TCP request-handling
classes that you still have to over-ride functions to actually
_do_ something with the request socket, but at least it _gives_
you a per-connection socket.

the SocketServer framework basically provides a common API to
create, handle, finish and close requests.  you don't have
to worry about how the request gets _to_ you: you only
have to provide methods to deal _with_ the request.

so you combine the above classes to get:

ThreadingUDPServer
ThreadingTCPServer
ForkingUDPServer
ForkingTCPServer

and, with the addition of BaseServer, i created
ForkingSQLTableReadingServer, which polls [yes, i know]
a SQL table, locks it, reads one entry, deletes it from
the table, unlocks the table,
creates a handler for it, passes the entry to the
handler, the handler Does Its Thing (in this case,
loads from a SQL table a python script named in the
request and runs it!)

now, whilst this level of genericity is probably excessive,
it was trivial to do, and it also provides the means to
*transparently* add... mmmm.... SSLServer and then
mix it in with Forking and Threading and you change *zero*
lines of code - ssl is all done for you.

redirection.  loop-back testing.  unix-domain-socket server.
even a TransactNamedPipe server - whatever you can dream up.


> It seems that the apache server framework can be extended 
> with other protocols by just adding new modules and filters.

... what if people don't want to add new modules and new filters?

what if they want to go a separate route but take advantages
of the best bits of httpd's code, and share the results?

:)

luke