Erik Moeller wrote:
the past few
days I've been experimenting a bit with Apache, mod_perl,
MySQL and creating an entire own website. I've never done that before,
and I think I've learnt a lot from this.
Great. mod_perl rules. Are you using DBI? In that case, it should be
relatively easy to switch to PostgreSQL.
Does PostgreSQL support replication?
I encourage you to move forward with this, and to
commit all code to a
separate CVS module.
Well, to be entirely honest, I'd rather not use the SourceForge CVS
server. It's cumbersome and full of problems. It doesn't work in Linux
for me, and in Windows I have to keep entering my password for every
single request (not just the commits).
The current code design is very messy
So *that's* why I didn't understand a bit of it! ;-)
If you don't want to do this, you will end up
very disappointed and frustrated because we won't adopt an incomplete
solution. Any new version should at least have the features listed here:
http://wikipedia.sourceforge.net/features.html
Whee. You have a list of requirements. That is a Very Good Thing Indeed.
I guess I'll copy this to my User page and then tick things off as I
finish them.
That's a *lot*. In addition, if you really want to
provide advantages over
the current codebase, please *document* your code.
Yep. If there's one thing I hate, it's missing documentation. However, I
like doing it later. Once the thing is finished and I know it works and
does not need any more significant change, I can document it, or else
the documentation will have been for nothing.
I still haven't bothered to figure out through
line by line reading what every function does.
I have, and I couldn't make much of it :-) I didn't have that many
problems with LJ's code, even though it's equally badly documented. (And
no, I don't think it's solely because of PHP.)
Perldoc is a great way to do this.
OK. I've thought about using some sort of documentation system like
that. I've never done that before though. I'll have a look.
The current documentation of your database schema is
completely
insufficient, though. Each table needs its own comment header explaining
what it does, how and why.
Yes, of course I understand this. I didn't do this yet for the reasons
mentioned above. Even now I have already changed some tables again. I'll
document them when I feel I'm happy with them as they are.
Here is some other stuff that would be important for a
redesign:
* have some kind of built in profiling
What exactly does this mean?
* test each query on a large dataset before including
it
Yep
* have some better way to handle edit conflicts, for
example, CVS style
merging
* have a better way to handle discussions, e.g. "Post a comment", "Reply
to this", but still do it using wholly editable wiki-pages
* have a category system built right in, perhaps using a meta namespace
Already planned (though that latter one would be near the bottom of the
list)
This seems to assume that images would have to be stored in a file
system. I think it's better to store them in a database, possibly one
separated from the rest.
* have a template system that can be used by the wiki
user:
http://marc.theaimsgroup.com/?l=wikitech-l&m=105557077500936&w=2
this could perhaps be combined with the general template system.
I have indeed planned such a template system, but I'm not sure what you
mean by the "general template system". Is that referring to the site
skin system? I'd really rather keep those two separate. They are not
related enough concepts.
Greetings and thanks,
Timwi