Wikitech-l January 2003

wikitech-l@lists.wikimedia.org

45 participants
143 discussions

Re: [Wikitech-l] "View user page" edit links on anon talk pages
by Takuya Murata 30 Jan '03

30 Jan '03

>Very soon now, the server will be owned by the nonprofit foundation. Oh, really. Do you have more information regarding this? I'd love to mention about this in wikipedia article.

1 0

Re: [Wikitech-l] [hardy@math.mit.edu: edit conflicts]
by Erik Moeller 30 Jan '03

30 Jan '03

On Mit, 2003-01-29 at 22:24, Michael Hardy wrote: > > yes, we need a better way to handle edit conflicts; but in any case, > > your work should not be destroyed! Unless something went very wrong, > > you should be given two edit windows, one with the new version saved > > by someone else and one with your version, and a list of changes. > > > This has not happened. I was using a version of Netscape > that may not be up-to-date; I'm not sure what would happen on > Mozilla or Internet Explorer. Please let me know if you can reproduce this problem, and if so, under which conditions it appears. > > 2) Show a warning if someone has started to edit the text < x minutes > > before you have > Or maybe a warning if they start to edit _while_ you are > editing, We can only show the warning when the edit page is loaded, i.e. to the person editing after another person has started doing so. We need a time limit because otherwise people could get the warning indefinitely if someone opens an edit window and doesn't save. Regards, Erik -- FOKUS - Fraunhofer Insitute for Open Communication Systems Project BerliOS - http://www.berlios.de

1 0

Re: [Wikitech-l] "View user page" edit links on anon talk pages
by Takuya Murata 30 Jan '03

30 Jan '03

>It seems it's usually Brion who commits stuff here, but it's >less formal than with Linux kernel. So, it is a kind of arbitrary. >And it's Jimbo who owns servers. What do you mean? I thought Bomis owns the server. Am I right? >Anyway, this was rather uncontroversial change. I don't remember saying it is controversial. I am sorry for giving wrong impression. I was just wondering about the decision process. I don't mean to object to this change at all. (though I advocate the system should be more democratic)

3 2

Re: [Wikitech-l] "View user page" edit links on anon talk pages
by Takuya Murata 30 Jan '03

30 Jan '03

>Most policy decisions should be made on wikipedia-l. I see. > doing it on the wiki itself might not help. Why is that?

2 1

Old table locking
by Brion Vibber 30 Jan '03

30 Jan '03

Just a note; of our current slowdowns, many are coming from locks on the 'old' table (which is still MyISAM, not the new table type). I'm going to try tweaking the sort buffer a bit, as I notice a lot of the stuck threads are in "sorting" state. We may want to look at queries using the old table (reads: history list, diffs; sometimes show old version. writes: inserts on page edit; updates on rename; deletes on delete. There _oughtn't_ to be too much contention on this table.) and generally fix stuff up. -- brion vibber (brion @ pobox.com)

2 1

Re: [Wikitech-l] C again :-) for worried Wikipedians
by Takuya Murata 29 Jan '03

29 Jan '03

>On Wed, Jan 29, 2003 at 01:51:48AM +0100, Pieter Suurmond wrote: >> Takuya Murata wrote: >> > The problem is set up. Surely the current dependency hell >> > makes hard to host mimi-wikipedia, particularly on windows- >> > based servers. > >No, you got it all wrong. >It's not "dependency hell", it's "server-side programming". Oh, how can I say. First, please recognize the context. If we distribute wikipedia server to hunders of mimi-server, it is necessary to make easy to set up. But if we don't, the dependency really doesn't matter the >We're supposed to use whatever we find convenient on server- side. >That's the paradigm on this side of network connection. Gentelly notice the debate should be based on the reasoning not simple assumptions. >These dependencies aren't really that weird - Apache, PHP and MySQL I don't think these dependencies are weired neither. >As for windows servers, it doesn't really matter. >They are rather small minority, and have so many problems >that supporting them is not really worth effort. >Just get some Unix. Again, if you distribute, the number of windows servers does matter. But again the context depends.

1 0

Search engine
by Brion Vibber 29 Jan '03

29 Jan '03

Our search engine desperately needs retooling. If there's no objection from those in the know, I'd like to migrate us to MySQL 4. The fulltext search in 4 has boolean capabilities built right in, meaning we could remove our hackish and buggy parser, and wouldn't need to stack so many MATCHes together in a query when some poor sap types in "chemical composition of the earth's atmosphere oxygen nitrogen" or something. (Our search queries are also frequently *dog slow*. This is exacerbated because, being a myisam table, it locks when someone tries to write it and another read is pending. I don't _think_ this lock virulently spreads to other tables joined with it, but it's annoying anyway.) Other things to think about: * Stopwords. Can we just get rid of the damn stopwords and search anything? * "Title results" vs "Text results" - this two-prong approach is, I think, rather confusing. We could have a single search index field with the title text weighted more heavily (by repetition?), and just give a single set of results. * Text extracts: these show the raw wikicode, and often include language links, HTML code, etc. Yuck! If we can strip these, that might be good. * Character entities: should be folded to their raw equivalents in the search index, so searching a page containing "Schrödinger" and one containing "Schrödinger" gives identical results. * 'Power search' is perhaps a little confusing, and there's currently no way to get to it short of doing two searches. * 'Search' and 'go' buttons are not clearly demarcated; several people have noted confusion. Better labelling or better arrangement is needed. * Redirects. We generally want to filter out redirects that seem duplicative of other things already listed, but *must* show them for alternate names. Clearer labeling of redirects would help as well. -- brion vibber (brion @ pobox.com)

4 3

Re: [Wikitech-l] "View user page" edit links on anon talk pages
by Takuya Murata 29 Jan '03

29 Jan '03

>Why in the world are we now giving anon users the option to create user pages? Also, I was wondering where such a decision was made. The main wikipedia mailing-list? The decision process should be more clear and more democratic. Best wishes, Takuya Murata

3 2

"View user page" edit links on anon talk pages
by Daniel Mayer 29 Jan '03

29 Jan '03

Why in the world are we now giving anon users the option to create user pages? Talk pages are a good idea but please don't display an edit link to "View user page" on anon talk pages. We don't want to give them too much since that will only result in fewer of them actually signing up for and using a user account (which is still something we want to encourage, no?). --Daniel Mayer (aka mav)

2 1

Re: [Wikitech-l] mimi-wikipedia
by Takuya Murata 29 Jan '03

29 Jan '03

Hello, everyone >Rendering a Wikipedia article requires, for example, to look up all the >links contained in it and determine if the pages exist or not. What else do we need to render wiki-marked up text? Aside from images, I don't see any other parts that require access to the main index. >Actually, we had a *decrease* in traffic in the last month due to the >Google hiccups. I know this. We should be able to cope with much higher traffic if we >optimize our queries. Note that pure bandwidth is not a problem; the >database tarball downloads are very fast. Ask Brion for the server specs >and be impressed. Ok, so the problem is cpu usage or database optimization stuff. I think you are right. If the database and queries to it is too complex, decentralizing hardly improve the performance. By the way, notice I am not talking about only the performance but also scalability and extenability. What about such a case? >2) You cite Google as an example of a huge centralized database No, I cited it as an of 'decentralized' database. >Trust me, wiki is *very* hard to decentralize. It's a nice idea, but it >will take years until it happens. You need an architecture like Freenet >( http://freenetproject.org ), only scalable (which Freenet is not), >plus SQL-like query support. While it is nice, it seemed for me only solution eventually. I think finally see the gap of understanding. I was talking about years-long project. I was talking about the time wikipedia reaches the next milestone 1,000,000 (million- pedia? haha). It seemed that eventually we have to go to the same path that big sites like google or amazon went. As you and I know, Google is heavily decentralized and it is one of its strength. I bet you know about load balancers (I know almost nothing about it thought). In my knowledge, most of huge sites decentraize their site to mimi servers like Google. We, of course, don't have finance to sustain such a huge decentralized data-center. But we have decent democratic community. The strehgth of us is that community. As I wikipediaholic (ach!), I am so worried about the future of wikipedia in terms of the server. We need definitely better solution (if not necessary my decentralized server idea). Possible solution includes the proposal Pieter's published scripts or better web-site for wikipedia developers. (It seemed quite a few people who are actually coding for wikipedia, compared with the scale of wikipedians writing articles) >wiki is *very* hard to decentralize I knew this. But can we figure out about how in here? I am not saying you do what I told. I can cooporate of course, tons of skilled programmers can do too I guess. If you think this debate is totally wasting time (I mean if I, who knows little, am annoying this mailing list), let me know then I quit but if not, please give me a comment. Okay, how about this? It seems to me that one of core problems is rendering requires queries about whether the page exists or not. I remember the post saying the rendering of a page containg many internal links is one of bottleneck (I suppose it is still true). First, each mimi-wikipedia has a database about if the page exists or not and subscribes the list of newly-made pages. Also, when it is launched, it downloads the complete list of new pages. Because now that each mimi knows which page exists or not regardless its mimi-database, it is possible to render the page without querying the main database. For disclamiler, probably I am wrong. But if you can, can you tell me why and how so? Anyway, I understand wikipedia still can be optimized much (that I didn't know in the first time I posted my proposal) Sure, if we can optimize the database and it gains the huge increase in performance hopefully, we should head for there of course. The priority should be optimization of the database. I agree. Anyhow, I approciate your detailed explanation about the problem we face now to me who knows really little.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l January 2003