On Mon, Dec 09, 2002 at 03:32:13PM -0500, Poor, Edmund W wrote:
What is the problem we are trying to solve?
The problem *I* am trying to solve is that I like the Wikipedia style of Wiki, but MySQL will get installed on my machine over my dead body, and I don't like CamelCase linking or CVS backends or having to use PHP or Java on my secure box to run a halfway decent Wiki.
There is also the problem of scalability (current generation of software has already reached it's limits).
Then there is the desire to fold the other language Wiki's back in as smoothly as possible.
Finally, I want to be able to easily adapt the software for use with other organizations.
How does the current software help solve this problem?
You mean the current design work on mod_wiki?
It solves the MySQL problem by using Postgresql.
It solves the scalability problem by reducing the amount of database accesses and "work" to be done by the CPU, while still allowing other Wikipedias to run independantly on other boxes.
It solves the use by other oganizations by factoring out the SQL statements and HTML snippets into proper files, templates, and customizable database tables of their own.
What does the current software do to cause this problem or make this problem worse?
Current software is too monolithic to be able to easily make the kind of broad changes I want to.
What will the proposed solution do, to address the above.
Be modularly designed. Also, written in C as an Apache module. May also include adding additional functions to Postgres, written in C.
The idea is to put the code where it can do it's work with the least amount of shuttling data around that is possible.
How can we test the proposed solution?
You download the source code from a link I provide, compile and run it. There will be no source code until I am satisfied I have at least a passable first working draft of a design document though. The better the design, the less coding work I have to do.
If you have any more questions, please post them to this list.
Jonathan