Yesterday, Erik Moeller mentioned that it might be best to hold off with
the wikidata development, and instead do that in a "quantum leap"
MediaWiki 2.0 version.
Which got me thinking: Should we start this (at least, plan it)?
There are quite some concepts and ideas that were proposed, but seem to
be hard to do with the current line of development. Examples:
* WikiData
* cur/old integration
* stable revision number for both cur/old
* single login
* XML parser
* use of wikicommons
* centralized interwiki link management
* stable/editable version management
* SVG support (editable SVG source?)
These are just the ones I come up with in a minute. There are, no doubt,
more.
Sure, some of them *can* be integrated into 1.3/1.4, but considering the
sum of the above, it might call for some radical break.
Which leads to the question: Fork or rewrite?
Seriously: If the database structure in 2.0 would greatly differ from
1.4 (which is to be expected), a rewrite of the core parts is in order.
* The parser will be rewritten anyway as XML-interpreting.
* We can probably keep the skin system
* Special pages will need a (partial) rewrite, depending on the new DB
structure
* Cache/squid/... can probably stay as they are
DATABASE REWRITE PROPOSAL
I vaguely remember there's one on meta, but I came up with this last
night (don't ask;-), so here goes nothing:
* Object list table. An object is a page (article, talk, etc.), an
image/media/binary file, or data; extensible with future types.
* A table for each object type, which holds the actual data: Article
text and user comment, revision number etc.
The object table only contains an ID and name (+namespace) for the
object, and an ID number for the actual object in its table.
So:
* OBJ_ID, OBJ_TITLE, OBJ_NAMESPACE identifies the object
* OBJ_TYPE (0 for page, 1 for image, 2 for data...)
* OBJ_DATA_REVISION identifies the current object data *in its table*
An article has
* ARTICLE_ID (matches OBJ_ID)
* ARTICLE_REVISION (both cur and old; OBJ_DATA_REVISION has the latest
ARTICLE_REVISION)
* the text of that revision, the user id, text and comment, and all the
other goodies
An image table would have
* IMAGE_ID, IMAGE_REVISION
* filename of the stored image, or reference to an external image
(commons), with a local description
Similar for data etc. (maybe even users?)
A table for changes would thus store an OBJ_ID. Recent Changes can then
look up what that object is, and then look up the changes in the
appropriate table.
As a result, we'd get
* an "universal" interface for everything we store in the wiki
* a (relatively) small table with all objects, equaling faster access
times, that only references the actual data (in the appropriate table)
Now you see why I think "rewrite" for this one. I also strongly believe
we should put *every* database access into the database class, capsuling
it from the rest of the software. Had we done this in 1.4, basically
only a rewrite of the database class(es) would be in order for the above
proposal.
Enough shocking you for now,
Magnus
I'm about to commit a major change to the 'old' table in HEAD. There
should ideally be no problems, but it's quite possible it will end up
corrupting your database, deleting articles or their histories, or
doing other bad things. There will almost certainly be minor bugs.
If you have anything important in a 1.4 version database, you MUST
backup your database before updating or you WILL lose it!
You have been warned.
Kate.
Hi!
I've posted about this before, but here it is again! :) In my
lex/yacc-based parser, I have now finished the table wiki syntax as well
as template inclusions. Please test everything! :)
http://timwi.dyndns.org/wiki/tmp.php
In particular, please test to see whether any invalid mark-up produces
an error. It shouldn't. It is always supposed to generate *something*.
If you do find an error, please e-mail me the full test case you entered
that produces it. (Alternatively, of course, ICQ and AIM work just as well.)
Things I know I haven't done yet:
- HTML tags (currently everything between <something> and </something>
is treated as an 'extension'; I need to limit that to <nowiki>, <pre>,
<math>, <hiero>, <music> and <chem> for now)
- [http://url/ These sort of links]
- hrs (horizontal rules)
- the new -{ language variants }- syntax
If there is absolutely anything else missing, please let me know!
(Please notice that the above URL is a bit slow at times when my
computer is a bit loaded. Also notice that it is only available when my
computer is turned on, which is during the day-time in the UK.)
Thanks!
Timwi
Apparently, Webalizer stopped working at September 27. Additionally,
stats for September 24-26 seem to be comparatively low.
Please, could anyone look after it [and fix it ;-)], as they are really
useful and interesting? (For example: compare John Kerry and George W.
Bush in September-stats (
http://wikimedia.org/stats/en.wikipedia.org/usage_200409.html ) )
Thanks,
Henning
--[[de:Benutzer:HenHei]]
It is today October 1st, and the page http://en.wikipedia.org/stats/
was last updated September 27th. It should be updated daily.
Furthermore, the numbers for September 24th thru 26th seem
unrealistically low. The same goes for other languages.
What's up? Are we losing Webalizer again? Why? Is the disk full?
It has worked fine in July and August.
Lars Aronsson, lars(a)aronsson.se
--
Aronsson Datateknik