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