cms 4 static pages?

Daniel Fetchinson fetchinson at
Thu Nov 4 16:21:18 CET 2010

> m looking 4 a framework, that allows to build static community software
> (similar to facebook) without having to start scripts, database
> connects, admin cookies, e.t.c.
> means - should be dynamic without really being dynamic, delivering just
> static pages. (yes, i know e.g. nginx does that by caching, thats not
> what i want!)
> features wanted:
> a not database driven
> b password access ist done by just renaming users home directory. User
> at logout will receive new secret subdirectory name 4 new login.
> c no clientside scripting. changing layout will be done by rebuilding
> all relevant static pages in user directory once by serverside script.
> d new entries e.g. mail, discussions will be queued, user just sees: tnx
> 4 your new article, page will be rebuilt in ... estimated 3 seconds ...
> or estimated 10 seconds ... depending on load and todo queue length.
> e load balancing is done by just replicating static pages between
> servers after new rebuild of static pages.
> f simulation of received mail directory through just rebuilding relevant
> static html tree. attachments not allowed.
> g intelligent todo queue 4 resorting mail sent, received, discussions,
> look and feel before rebuilding static user pages. (herein lies the
> intelligence of the whole system)
> h notifications 4 new mail, messages, e.t.c. are just updates in static
> html fields. if user gets offline (measured by time since last update of
> static pages) user will be informed once a day by mail.
> i simulation of locking can easily be done by dotfiles.
> j according 2 my calculations such system should be able 2 satisfy any
> bandwidth without causing significant load of cpu, due 2 low protocol
> overhead and no server side scripting, no database load. overload of
> server should not possible by design.
> k modules, addon 4 twitter e.g., nice 2 have
> (and no, no java!) any pointers?

Yeah, rethink your design!

Seriously, you listed a number of features which are not really
features but implementation details and you haven't told us what your
original goals are which you think are fulfilled by these
implementation details. If you would clearly state what your goals are
(regardless of how it is implemented) I'm 100% certain a better
implementation can be found than the one you enumerated.


Psss, psss, put it down! -

More information about the Python-list mailing list