Complete.Org: Mailing Lists: Archives: gopher: April 2002:
[gopher] Pygopherd 0.5.0 available
Home

[gopher] Pygopherd 0.5.0 available

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Pygopherd 0.5.0 available
From: John Goerzen <jgoerzen@xxxxxxxxxxxx>
Date: Mon, 8 Apr 2002 15:55:22 -0500
Reply-to: gopher@xxxxxxxxxxxx

New in this release:

* Refactoring of module layout to make it more hospitable to systemwide 
installation.

* New vfolder support -- a generic mechanism for virtual file/folders

* MBOX handler rewritten to use vfolder.  Maildir support trivial to 
add, done.

* New PYG support -- see below.  PYGs are basically Pygopherd's version 
of CGIs or executable scripts, but with some unique twists.

* Optimizations in the code that result in about a 4x speed increase in 
rendering large directories -- excluding caching

* Protocol-independent directory caching mechanism.  Implemented in 
dir.py so available for both regular dirs and UMN dirs (UMN dirs are 
implemented by subclassing dir.py)  This results in a substantial speed 
improvement by caching all the processor- and disk-intensive things, and 
yet not caching the protocol-specific data.

About PYGs:

A PYG (PYthon Gopher module) lives out in the gopher filesystem 
somewhere.  It generates data to send back to the client -- sorta like 
the bucktooth way of executing a separate script.

When a PYG is encountered -- either when directly requested by the 
client or when information about it is requested for generating a 
directory listing -- its python code is loaded up as a separate module 
INTO THE SERVER PROCESS.  Its PYGMain class is instantiated.  From this 
point on, it becomes virtually the same as a first-class handler in 
Pygopherd.  First-class handlers are the things that send files and 
directories back to clients.

A PYG class can implement the four main methods of a handler: 
canhandlerequest(), getentry(), prepare(), write().  Just like regular 
handlers, a PYG can write directory entries -- always in the correct 
protocol -- by calling self.protocol.renderdirentry() and passing along 
a GopherEntry object.  Simple, elegant, clean.

Here are the benefits of this architecture:

  * All PYGs automatically support all protocols supported by the server, 
including ones they never knew about.  The server does not need to do 
any post-processing of PYG output.

  * PYGs are loaded without an additional fork()/exec()

  * PYGs benefit from the existing handler class hierarchy and the 
functionality in there.  (Want to implement a MH mailbox handler?  
Override the Maildir one in the PYG and make a few changes.  Probably 
less than 10 lines of code total.)

  * PYGs can access the master configuration file.  This file can have 
sections specific to PYGs.

  * PYGs are powerful.  They have powers of self-determination and can 
assert the inability to deal with certain types of requests (via 
canhandlerequest()) just like a regular handler can.

  * PYGs can return any type of data they like to the client.  Because of 
the getentry() support, both the client for a particular request (ie, a 
HTTP one) and the parent directory generator know what sort of data the 
PYG is going to be sending.  All without extra work in the PYG.  Rather 
than telling the PYG what sort of data to send, PYG tells pygopherd what 
data is forthcoming.

Comments welcome.

Downloads at the usual places.



[Prev in Thread] Current Thread [Next in Thread]