[gopher] Pygopherd 0.5.0 available
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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.
- [gopher] Pygopherd 0.5.0 available,
John Goerzen <=
|
|