Erik Moeller wrote:
Timwi-
You definitely should use a CVS server if you expect any kind of constructive contributions.
Yes, I know :/ Thanks for your hints, but I think I'll stick to SourceForge just to go with the majority.
- have some kind of built in profiling
What exactly does this mean?
Keep a log of how much time is spent within each function
Oh, *that* kind of profiling. I have done that with C++ applications under Windows, but I never thought it'd be necessary for webserver applications... Clearly, at least our *current* problem - and also the current problem of LiveJournal (sorry I keep mentioning LiveJournal, but it's the first and only other major website I've major contributed at) - is database performance, not CPU usage.
Categories will likely go live soon (if Magnus finally finishes the damn thing), so a compatible scheme needs to be in place if we want to switch over.
Yes, point taken, but I don't expect the switch to happen soon :-) In fact, I don't really /expect/ the switch to happen at all, I regard it all as an experiment. Even if Wikipedia won't ever use my software, it was still a lot of fun and very educational to write it.
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.
I never understood this approach. It only seems to be associated with increased risks (reduced performance, increased risk of data corruption) and have no benefits. What exactly is the disadvantage of just storing a pointer to the local filesystem in the DB?
I suppose you're thinking there's an increased risk of data corruption because the database is all one file, and you're thinking if one bit of the file gets corrupted, it's all gone. As far as I have been taught, however, this is not actually the case. Any argument in this direction applies equally to file systems. If a range of bytes in the middle get corrupted, it would likely corrupt only one image/file. If the directory structure got corrupted, the file system would also lose everything.
The "reduced performance" argument is something I don't know anything about; it is possible that this is a good argument, but I'm not convinced.
Now to your question, "What exactly is the disadvantage of just storing a pointer to the local filesystem in the DB?" - The disadvantage is that it is more difficult to maintain a consistent state, i.e. a database without "dead links" and a file system free of orphans. Does this make sense? You can easily copy part or all of the database to another database or a backup medium or something, whereas with a filesystem you'd have to be careful not to copy database entries and then forget to also copy the relevant files.
- 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.
I do think there are similarities between the two. Any good template system, for site skins OR for internal rendering, will have to support things like loops, conditional blocks etc. This stuff needs to be parsed, so you might as well use a single library for doing so.
You have convinced me about this. I'll try to combine the two.
You are using proper object-oriented design, I hope?
Hm. I haven't even thought of this. Thanks for pointing it out soon enough. :) I'll try to make things as object-oriented as possible. That will add to the educational nature of my experience, because - although I've done extensive object-oriented programming before - I've never done that in Perl (though I've read code that uses it). Should be fun :)
Greetings and thanks, Timwi