ANN: Pocoo (bulletin board software) 0.1 beta released

[Paul Rubin]

Georg Brandl <g.brandl-nospam at gmx.net> writes:
> Pocoo <http://www.pocoo.org/> is a bulletin board software
> (aka. message board) written in Python, adhering to the WSGI
> standard. In the long term, it is meant to compete with systems like
> phpBB.

You too, huh?  I've also always wanted to write one of those.  Mine
would be performance-intensive.  I've never understood why the phpBB,
vBulletin, etc. systems that I use bog down so much.  It's a very
serious problem--the bigger boards I hang out on all have to use
multiple servers, resulting in big hosting bills ($1000's per month),
so they have to take advertising, hold fundraisers all the time, etc.
But the raw hardware really needed if the software were any good,
including adequate bandwidth, should fit within the cheap
managed-hosting servers (typically a 1U rack-mounted single processor
Celeron box for $100 a month or so) or on a VPS for smaller loads
($50/month or less).  That means the hosting fees can be paid out of
pocket by a few donors, getting rid of all kinds of fundraising
headaches and increasing organizational and content flexibility a lot.

So, I think it's not worth thinking about writing yet another BBS
unless it can handle a Slashdot-sized load on a commodity PC.  For
very large loads it should be able to use multiprocessor hardware
effectively (an 8-core Athlon server costs as much today as an entry
level engineering workstation of the 1990's).  I've even played with
the idea of using MPI for this ("imagine a Beowulf cluster of...")
which would let you couple multiple boxes together with ordinary LAN
hardware, letting you scale straightforwardly to hundreds of cpu's.  I
think it should be possible to do all this, using a system still
written mostly in Python.

My suggestions:

1) ditch the SQL back end, or at least don't depend on it.  Someone
had the clever idea of using an NNTP back end, using a news server (or
a network of them) as a message store.  That gets you all kinds of
features for free.  Otherwise, keep all messages in an mmap'd disk
file that can be shared in memory between multiple processes.  Adding
messages would append to the file, and to some kind of log that would
reconstruct in-memory structures in the event of server restart.
You'd also need some IPC synchronization scheme.  

2) Look at the architecture of WebCrossing and also of OKWS (www.okws.org). 

3) Hmm I had some more, I'll keep thinking.