I saw mention on our tentative hardware order [1] of disk space for log
files, although not specifically the traffic logs. I believe Kate mentioned
we generate around 2GB per day, which means we have around ~360GB of these
sitting around waiting to be processed. Would it be possible to purchase or
set aside a server or two to take care of this, with the (perhaps pipedream)
goal of then running webalizer every day?
[1] http://meta.wikimedia.org/wiki/Hardware_ordered_March_2005
/Alterego
I know of many users having asked for implementing this, but how do
_you_ like this ?
Shall we notify changes on both pages ?
I have 1.4.1 code ready for allowing old or new behaviour (settable in
DefaultSettings).
Would be nice to learn, how you think about this.
Tom
Hi All!
Does everybody know how export from wikidb just only wikitext
(wikidb.cur_text table) to html files?
I've tried to use Text_Wiki module but now it doesn't support full
MediaWiki format.
Is any PHP classes which provide API for it?
Thanks
Sergey
> If you could post temporarily the previous 2-3 dumps of the English datatabase that would help me a lot. Thanks! bj.
Right now we've got high usage on server holding March dump, if you can use dumps provided by community, that'd ease a bit our and hardware work on server side.
Cheers,
Domas
Hi -
It occurred to me that the 500k+ english language article topics would
by themselves be a fairly broad index of the vocabulary and zeitgeist
of the english speaking world - which would, in turn, potentially be
quite handy as word list for constructing US-style crosswords and the
like.
While I can presumably generate such a list from the backup sql dumps,
that's obviously the hamfisted, bandwidth-sucking way to do it.
Particularly since I'd actually prefer a simple, big tar'd and gz'd
text file.
Suggestions? Does this already exist somewhere I didn't find?
Thanks -
Andy
----
The ability to quote is a serviceable substitute for wit.
- Somerset Maugham
In 1.5 (assuming there are no objections), image width, height and bit
depth will be available in the image table of the database. This is
mainly for scalability. It allows replication and read load distribution
of this commonly requested data to be handled by the database, where we
already have tools for such things. A simple future extension would be
to bundle metadata queries for all images to be displayed on a page into
a single query. This is only a few lines away now, but was not possible
with the original NFS-based system.
Thumbnails are still not handled in a way suitable for our scalability
goals, this will be my next task.
The code is in CVS.
-- Tim Starling