On Fri, Jul 25, 2003 at 01:42:29AM +0200, Timwi wrote:
Lightning wrote:
Plus, I think there was a reason behing
programming
in php vs Perl, im not sure..
Read the section "Why are we using PHP instead of perl?" on
http://www.wikipedia.org/wiki/Wikipedia:PHP_script_FAQ
Selecting the language to use for Phase IV we should
think about the features it has to provide.
I think we would benefit from a framework that provides
easy to use shared information, information that any
running instance can immediately access. Things like
localization strings, Recent changes or other frequently
requested but dynamic data.
Currently, localization strings are initialized for
every request and thrown away afterwards. They could
be a "global ressource" that's initiated only once.
I know that Java servlets provide these (initialize a
hash during the init of the servlet and store a reference
to it in the servleti), and that PHP doesn't. I'm not very
good at mod_perl, does it allow e.g. a design of
Recent Changes as a big array? Instead of writing a
dedicated Recent Changes table it would be enough
to write edits line by line to a journal and reload some
thousand lines of journal on a server restart.
This would save us a lot of database queries (for RC),
or allow dynamic changing of the localization strings
while still having high performance (currently changes
have to go through CVS before being applied to the
production server, very slow process)
Then add to
that that you designed a new db schema
and that all data will have to be converted from one to the other
Of course I have thought about this. My plan would be to convert
articles as they are requested by readers. That way the database would
get converted gradually on demand, thus minimising possible delay and
avoiding downtime.
This will be very hard to maintain if you want to have the special
pages reenabled. You will have to do lots of joins and subselects.
Nothing MySQL is very fast at.
"If
it's not broken, don't fix it" I currently see no problems
with the wiki software as it is.
Well, please allow me to reply something to this even if it may
potentially be somewhat offensive. If it is, I am very sorry, and I do
not mean to offend you. But the reason for this is that you are American
and (as far as I can tell, sorry if I'm wrong) only use the English
Wikipedia. People who are using several different language Wikipedias
are seeing many more disadvantages and shortcomings in the current
design. Add to that the fact that you are very much used to Wikipedia as
it is now; it is often difficult to forego something familiar.
Additionally, the current database schema has performance problems that
you will not be able to overcome without converting the database. Of
course, you could convert it bit by bit, but then again, you could
equally well start with an entirely new database schema...
I don't think the database schema is the source of our problems, I thinks
it's the RDBMS. The slowdowns I have observed (Sudden slowdowns for a
minute or two, server being fine afterwards) are always around the saving
of a "List of ..." kind of article. This looks like locking issues that
other RDBMSes that are not optimized for "read mostly" do not show.
and some info
about your ideas for then ew software
Well, I've had quite a lot of ideas, I probably wouldn't know where to
start. Of course, I have followed this mailing list and have picked up
ideas here and there. I support the idea of a more-or-less independent
layout system that will allow users to skin Wikipedia to their needs
without the software needing to hard-core any HTML (with the possible
exception of the contents of pages in the Special: namespace).
Other (not-so-important) improvements over the current system include
translatable names of Special pages (not just the namespaces), all
non-canonical URLs redirect to the canonical URLs, so every resource has
one and only one place to live; easier URLs (/Article_name/edit instead
of /w/wiki.phtml?title=Article_name&action=edit), being able to use
Wikipedia's web interface in one language while viewing articles in
another language ...
just please don't post perl source full of
perlisms like $/,
$_, $? @var, %var. etc that crap is obfuscated and hurts my eyes..
I haven't used $? yet :)))
I suddenly remember why I don't like Perl ...
JeluF