[RANT] Re: lib/apr_signal.c

[David Reid <dr...@jetnet.co.uk>]

What does this have to with lib/apr-signal.c????

Come on guys, change the subject if you're changing the topic...

david


> 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
>