Lightning wrote: Heh, knew it! ;-) Read the section "Why are we using PHP instead of perl?" on http://www.wikipedia.org/wiki/Wikipedia:PHP_script_FAQ 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. 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... Unfortunately, any change that would introduce a universal-login system to the current system, would be a hack solution in and of itself, simply because the current software was not designed to handle this. http://meta.wikipedia.org/wiki/Experimental_new_database_schema Any comments, of course, are welcome. 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 ... I haven't used $? yet :))) But I have to admit to being a fan of regular expressions. I use a few of them currently to extract information from URLs (like the language code), but the two Special Pages I have created so far (Log In and Translate) do not use them at all, and I don't think most of them will (things like Watchlist, Recent Changes, Orphans etc.etc. will just be SQL statements and then an HTML table). Greetings, Timwi

Jens Frank wrote: Well, the particular feature you have mentioned isn't specific to a programming language. Yes, mod_perl allows you to store something in a global hash and keep the data between requests, but obviously this will only work if you have only a single webserver (which I hope we're not going for). This is a problem MemCacheD can solve - in fact, that's exactly what MemCacheD is for. And APIs for MemCacheD are, as has been said, available for both Perl and PHP (though the Perl one is the only one currently in use at a frequently-visited production website, livejournal.com.) Although the theoretical answer to this is 'yes', this is optimising at the wrong spot. I've said this before. The Recent Changes page is not a performance problem as long as it only reads (provided of course it is optimised enough). What really blocks the database is a write. With the current software and database schema, article text is inserted into 'old' and then also modified in 'cur' every time you edit a page - which is doubly bad because 'cur' is the table you read from when you to the most basic thing: displaying an article. It also updates the search index, which is accessed by the search function, which is probably the second-most-used function. I'm not exactly sure what you mean here by a 'journal' if not a dedicated database table? Well no, I wasn't really planning to have the database-intensive Special Pages (Orphans, Long articles, etc.) work with the old database. Especially Recent Changes doesn't need to because virtually anyone only uses the n most recent changes and no longer cares about those before the switch. Instead, I was planning to provide a Special Page listing all the articles that are still in the Phase-3 DB, and after a few weeks they'll all have been converted. It doesn't matter as much that "Long articles" and "Orphans" doesn't work reliably in this short interim period as it would if editing or even viewing articles wasn't possible. I have outlined the problems I see with the current DB schema in a posting to this list dated 12.07.2003 03:58, Subject "Database design": http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/004829.html The problem I mentioned above is only one of them. Don't get me wrong, I'm not disagreeing that Perl /is/ sometimes quite obfuscated - myself, I also hate the single-character variables ($/, $|, $`, $[, etc.). But apart from $_, they are all very rarely used. Please don't start a religious war about this ;-) Greetings, Timwi

Lightning wrote: Interestingly enough, I can't really say I don't like PHP. I just sort of feel that Perl already does the job, so can I can't get myself to learn PHP. :) Please trust me -- I know *exactly* how you feel! I was in the same position not too long ago. Heh, I even remember seeing this statement: $a =~ s/$/\/\//; For obvious reasons, this is discouraged even among Perl programmers. It's called the 'leaning toothpick syndrome'. An equivalent statement would be: $a =~ s!$!//!; but it's actually the same as $a .= "//"; or $a = "$a//"; or $a = $a . "//"; which is of course more readable by orders of magnitude. It is often possible to write Perl code which includes a regexp in such a way that the reader of the code doesn't have to read the regexp or understand how the regexp really works, but can nevertheless see what it does or what it's for: if ($url !~ m!^(\w+)://((?:\w+\.)*\w+)(?::(\d+))(/.*)$!) { return "Invalid URL format."; } else { my ($protocol, $host, $port, $path) = ($1, $2, $3, $4); # ... # ... continue processing ... # ... } It should be pretty obvious without looking at the regexp that its purpose is to check URL syntax and to extract the protocol, hostname, port number and path from it. (I've only just grabbed this regexp out of the air, so please don't hit me if it's completely wrong ...) Timwi

Hi Rotem, Rotem Dan wrote: Well, I'm neither a webserver expert nor a database expert, but I know how LiveJournal does it (and I've mentioned it here in the past). They use a number of independent webservers, and then put a "load balancer" in front of that. This load balancer receives the requests from the clients and distributes them evenly over the webservers. This way, if one webservers crashes, the site will only be marginally slower until this server is restarted. LiveJournal also has redundant load balancers in case one of *those* crashes. As for the database, they use MySQL replication. That means there are several databases actually containing the same data; one of them is the "master" (which is where data is written), and these writes are then broadcast out to the other DBs, the "slaves". This way DB reads can be even distributed among several servers. This, in turn, means you don't need to keep buying bigger and better hardware, only more of it (and the old and crap hardware can still contribute to handling some of the load). They (LiveJournal) have even written an independent Perl module (DBI::Role) which handles all of this (distributing DB reads across several slaves, and even weighting them according to their performance). Now, LiveJournal actually also use clustering, i.e. they distribute the users' journals across several clusters (each of which has an own master and several slaves). I'm yet undecided whether it's a good idea to do the same with Wikipedia languages. Doing so would make multi-language watchlists difficult. However, not doing so may make the architecture not scalable enough. I'm not knowledgeable enough to judge this. This is actually the part I'm looking forward to! (Since, as mentioned before, I love regexps ;-) ) Well, no. I wasn't planning to design or integrate a new interface. I was going to create a skin system that will allow people to create skins liberally without needing to code. Then you could create your skin yourself :-) Well, looking at what many sites have achieved with CSS (including but not limited to LiveJournal's Xcolibur scheme, which isn't yet the default), it does seem quite impressive. However, there are a few (probably minor) reasons I hate CSS, including but not limited to the incapability of simply placing something at the bottom of the browser window regardless of the main text flow, or centering a table. Also, making a site layout browser-independent seems to be even more difficult with CSS than with outdated HTML 2 (in my experience, anyway). Na-ah! No language files in /my/ implementation ;-) My translation system has everything in the DB. Translators can change the translatable texts using a web interface. (I specifically decided against applying the Wiki philosophy to this because things like the "Edit this page" link text apply to /every/ page on the /entire/ site, so it would be too easy to upset a whole bunch of people by changing it to something offensive.) Yes, I thought the same -- and have planned to make longer page contents (like the explanation on "Upload file" you mentioned) wiki-like, so they are actually the contents of the page titled "Special:Upload" (or whatever it would be in other languages). Well, actually, I'd really rather keep /some/ simple HTML formatting in-place. Sometimes you want to bold a single word in a sentence, but bolding looks really ugly in Chinese and Japanese, so /they/ prefer /not/ to do it. So I keep the simplest of formatting in, so translators have at least /some/ control over it. (I am, at least, planning to use HTML in translatable strings /much/ less than LiveJournal does now; they have a /lot/ of HTML in their strings, and sometimes even BML, which is their own mark-up language which nobody knows.) Yep, planned. Also a URL parameter to force the interface in a particular language. I am not aware of any language which has characters that are not included in Unicode, and I'm pretty certain none of the Wikipedia languages do. Of course, my implementation would simply use UTF-8 all the way through, thus avoiding all annoying encoding problems. (Well, not all of them; I've already handled the case that someone may request a URL which contained invalid UTF-8; I assume Latin-1 in this case, convert and redirect. But, of course, articles and all interface stuff would be entirely UTF-8.) Greetings, Timwi

I think you are missing the point of a templating system and how it works..... it has nothing to do with SGML.... its just a way to separate php code from html code.. just a simple information hand-off interface... Lightning

Erik Moeller wrote: Does PostgreSQL support replication? Well, to be entirely honest, I'd rather not use the SourceForge CVS server. It's cumbersome and full of problems. It doesn't work in Linux for me, and in Windows I have to keep entering my password for every single request (not just the commits). So *that's* why I didn't understand a bit of it! ;-) Whee. You have a list of requirements. That is a Very Good Thing Indeed. I guess I'll copy this to my User page and then tick things off as I finish them. Yep. If there's one thing I hate, it's missing documentation. However, I like doing it later. Once the thing is finished and I know it works and does not need any more significant change, I can document it, or else the documentation will have been for nothing. I have, and I couldn't make much of it :-) I didn't have that many problems with LJ's code, even though it's equally badly documented. (And no, I don't think it's solely because of PHP.) OK. I've thought about using some sort of documentation system like that. I've never done that before though. I'll have a look. Yes, of course I understand this. I didn't do this yet for the reasons mentioned above. Even now I have already changed some tables again. I'll document them when I feel I'm happy with them as they are. What exactly does this mean? Yep Already planned (though that latter one would be near the bottom of the list) 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 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. Greetings and thanks, Timwi

Erik Moeller wrote: Yes, I know :/ Thanks for your hints, but I think I'll stick to SourceForge just to go with the majority. 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. 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. 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. You have convinced me about this. I'll try to combine the two. 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

Erik Moeller wrote: IT was written to replace UseModWiki's built-in parser. So I think the syntax is identical. (We've improved stuff like nested lists... minor difference) Because it's OO, it's fairly easy to add new syntax rules.

Timwi wrote: For ten years now, I've been working with performance issues in systems that use databases, and I've never found it to be so easy as you want it to appear. Believing that "the problem is database performance" all too often leads people to blindly buy new hardware or change database software (from Oracle to Sybase or from MySQL to Postgres), as if printing more money would solve any "shortage of money" sort of problem. Instead, I think you have to look at *how* you *spend* the resources that you have got, and consider if you could spend them otherwise. If, perhaps, you are wasting and could start to save. As any economist can tell you, the first step is monitoring the current flow, to get an overview of what is going on. This is what the profiling is about. It's not about CPU performance or database performance. It is about locating the hole in the bucket. The resource that we've got to work with is the two to five seconds of patience that each user brings to www.wikipedia.org. Before that time runs out, they should have their content delivered. If we have a hole in our bucket, where all time runs out, we better plug that hole. If we make a single call to a database that takes seven seconds to respond, we better fix that call (or the database). But if our code for every HTTP request makes seventy calls to a database that always responds in .1 seconds (if you think this example is unrealistic, you haven't been in the telecom industry), the entire HTTP transaction also takes a total of seven seconds, and we better fix our code to make fewer calls rather than put the blame on the poor database. It's about wallclock time, not CPU time. And profiling is the way to go, if we want to do better than guess and pray. So far, the Wikipedia developers have mostly been guessing and praying. I think the worst performance I ever saw from Wikipedia was in May 2002. You can dig up the thread from the archives of this list, e.g. http://mail.wikipedia.org/pipermail/wikitech-l/2002-May/000344.html Right now, Wikipedia is flying and everybody is happy. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se/

Lightning wrote: Isn't code always confusing? :-) However, if you are looking *for* bottle necks, it means you are looking *at* the bottle. Try looking at the fluid instead. Nobody really cares about the bottle anyway. You're on the right track here. However, the first thing we do when we try to analyze that log file is to filter out all entries that have a short roundtrip or response time, since they are not a problem. So it is rather unnecessary to log anything that has a short roundtrip. We only need to log the slow responses. start = time(); ... /* do all the calls */ elapsed = time() - start; if (elapsed > OUR_THRESHOLD) Log("whooaaa, doing all the calls was very slow!!!"); Let's set the logging threshold so that only, say, 1% of all calls get logged. The overhead for looking at the system clock at the beginning and end of every call is neglectible. The overhead of writing a line to the log for 1% of all calls is also neglectible. There is no reason not to use this sort of logging in the live system. If "start" is a global variable, you can write a subroutine to make the whole program more readable: void TimeLog(string text) { time_t elapsed = time() - start; if (elapsed > OUR_THRESHOLD) Log(text + " took " + elapsed + " seconds"); } Then the progam will look something like this: start = time(); if (this_call == "GET") { ... /* do the get */ TimeLog("get"); } else if (this_call == "SAVE") { ... /* do the save */ TimeLog("save"); } else if (this_call == "STATISTICS") { ... /* do the statistics */ TimeLog("statistics"); } The overhead for calling this subroutine for every transaction is also neglectible. It is a matter of microseconds at most, and any "performance problem" is a matter of several milliseconds. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se/

I would like to ask developpers a question : I have a problem on my browser with indivisible spaces. Please, this is an important question, the sort of issue that might lead to an edit war. In french typography, indivisible space are put before some caracters, such as : Recently, a new editor (a french language teacher) got on the french wiki. He insists on using these unbreakable spaces. As far as I know, he is the only one. However, for some reasons I can't explain, my browser (a brand new one, last version, unicode friendly, page over 32 kb friendly, etc...) appears to be "breaking" these spaces. Though I can't figure how it is doing so. When I look at the history, I see nothing I can explain. Still, Vincent insists that I do break his text. To fix it, he has to either revert my changes, or fix them himself, isssue upon which he is strongly complaining so requesting that I fix the stuff myself. Fact is, I can't see what I do wrong, and I can't imagine myself editing by hand his comments myself each time I edit an article or talk page, to avoid removing the non-breakable space (if only I could figure how not to do so !) Let me show you an example : Here is my edit (I was removing a div in a talk page, use of div is becoming more and more common, as well as use of anchors to support 40 or 50 kb pages) http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82635… And here is Vincent next edit, restoring manually all the non-breakable spaces behind me http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82637… The fact is that if I see him restoring the spaces, I see not in *my* edit where I broke these spaces. I only removed the div line. I just look from my job browser (a very regular PC), and I can't see anything special either. Guys, this is a tough problem because that means either Vincent has to correct behind me each time, and complain loudly, and request that I fix the mess myself, or I can't edit the pages Vincent edits. This is doubly important as Vincent and I strongly disagree on other matters as well, so I fear this particular point might disrupt our peaceful little world. Is there anyone who would have a *clue* on that specific problem ? Is it solvable or not ? Are there other wikis using non-breakable spaces ? Did they meet problems as well ? __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

--- Erik Moeller <erik_moeller(a)gmx.de> wrote: I know. This is also why I remove the div tag after he used it for the second time on the same day (the first being on *my* page) And why I don't like the anchors he is putting everywhere. Since most of his articles are very long (but very good and interesting as well), he puts some anchors in the text, so links from other articles may lead to the good paragraph in the very meaty one. All this is good, but I dare not (and he wishes me not to) edit article such as the one on greek religion to avoid messing with the anchors. This is very unwiki ihmo, but when I protest, he says I am not the boss and this is only *my* opinion, and that I am forcing my desire of simplicity upon others, to the detriment of quality articles, which may be long, with sankrit or greek or whatever characters, and anchors, and non-breakable spaces, and div spaces :-(((( http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&action=edit This one is a nightmare to me. I have no idea what other people see here, but as for myself, it is scarry And since other editors either don't say anything or push the use of anchors, complicated html codes, fancy small bars, div tags and such, who am I to say anything all alone ??? This desolate me, but if the consensus is to make editing difficult, I can only try to salvage my little area of edition. http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82635… http://fr.wikipedia.org/w/wiki.phtml?title=Discuter:Ph%E9nix&diff=82637… Ah, yes, he absolutely does so. Word processor. I know because he lectured me on the fact I didnot know the proper usage of non-breakable spaces (which I do, but do not respect in the least ;-)). He gave me a link to a page explaining how to do non-breakable spaces from my editor. He also said any decent editor was supporting writing properly good french, and that I should not edit anything even on talk pages without having first run the grammatical/typo corrector. Because my editing without accents, and with spelling mistakes on talk pages was not respectful of readers. 'Cause we were not a chat, but an encyclopedia We've got to be serious ! This is no joke work ! :-(((((( !!!!! But there is *no* grammatical/typo corrector on a wiki edit page :-(( All I can conclude from this comment is that he is indeed writing all what he upload to wiki on a Word (or equivalent) editor first hand. Is that usual ??? It happens I prepare long articles on Word before, or that I save text on simpletext when there are lags, to avoid loosing them, but all I write is just straight edited in wiki. The only other person I apparently messed text a couple of times on our pump is Aoineko. Do you remember Aoi ? Do you write sometimes your text on editors rather than on wiki edit windows ? Well, I will try to explain that to him But he will probably answer that I am the only one doing so with his non breakable editor spaces. Thanks Erik __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

--- Fred Bauder <fredbaud(a)ctelco.net> wrote: yup; quite true Update : I posted Erik answer on our pump. Vincent comment was that I was intellectually dishonest, as the message was clearly from me, pretending to be someone called Erik. In short, he said the answer was a forgery ! I also decided not to be *too* bold, and before reworking the article, I matter of factly proposed a solution for division of the article and renaming. Vincent only answer was "I said I would take care of it myself" That is all. I think that won't make it :-) Anthere __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

--- Vincent Ramos <siva-nataraja+spam(a)alussinan.org> wrote: which is precisely why I apologized for not having recognise a troll at http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/005164.html and on your talk page. I agree a lack of capital and wrong quote marks are definitly signs I should have noticed. you are the one who express himself the best on the fr wiki. Now, you may wish to go on fueling the troll with screaming and bad words, it will just do what he wanted to get in doing so. Which would not solve our problem in any way :-) Vincent. This is *precisely* why anchors are wrong. When it comes to a point only the main editor (or should I say the only ?) is able to edit, rename, rework, add, remove to an article, because of a complex linking system, there is a problem. That is exactly what I mean by simplicity of edition. And no, it is not only *my* agenda to support this. That is what I have been trying to explain to you. You say you want other editors to edit your text, but at the same time, you say you would prefer they do not do so, because the link system is tough, and only you know where the links are. Well, yes, an article should not have only one author, and everyone should rework it without fear of messing the whole place. Please, if you do not understand that, say so here, so that perhaps somebody else explain better than I do. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Good to know it was all a false alarm... Fred Bauder http://www.internet-encyclopedia.org

Vincint, It is established policy to divide any article over 30kb since some browsers won't edit pages over that length. This is a settled issue. Fred Bauder http://www.internet-encyclopedia.org

Anthere- He can put his copyright on the page; you can remove the copyright AND change the text, since all submitted text is FDL-licensed and a copyright notice to that effect is already at the bottom of each page. Regards, Erik

Le Fri, 25 Jul 2003 08:22:02 -0700 (PDT), Anthere &lt;anthere6(a)yahoo.com&gt; a �crit: I've just told you how you could do this; rather simple but daunting. What kind of behavior is this? Will you then start crying? Of course, it's full of Chinese characters; as the French Wikipedia can't handle raw Unicode data, I have to use decimal entities instead. Laugh. I do not even own it; I use Babelpad, a raw Unicode text editor <http://uk.geocities.com/BabelStone1357>. But you still believe I'm wrong; please look a the raw source of your modifications with an hexadecimal editor. Frankly, I find this really childish. Nope. Of course: Anthere only modifies U+00A0, and not html entities. No.

On Fri, Jul 25, 2003 at 09:30:18PM +0200, Vincent Ramos wrote: Vincent, I doubt that your behaviour is acceptable by any means. Regards, JeLuF

Erik Moeller wrote: I agree. It's ugly in source. Why can't a browser see a text is in french and then treat a space between numbers or after punctuation as unbreakable? Has the w3c thought of this yet?

On Fri, Jul 25, 2003 at 12:15:35PM -0700, Anthere wrote: OK, looks like he is right. Anthere, which browser are you currently using so that we can try to find what is doing the change? Despite this I think wiki software for French Wikipedia should be changed to insert &nbsp;'s around colons, brackets, etc pp. to automatically render "good French" at reasonable editing efforts. Having those blanks unbreakable is what a computer should have to care about, not an editor. In which cases are those non breakables usually used? Regards, JeLuF

On Fri, Jul 25, 2003 at 08:55:23PM +0100, tarquin wrote: Agreed, but I think it might be easier to update wikipedia software than all available browsers. JeLuF

I'm not quite sure why you initiated this whole discussion in this thread of mine, because it doesn't really seem to have anything to do with my experimental design. Not that I mind really, but it will cause confusing threading in mail/news clients and the mailing list archive. Anthere wrote: I haven't tried Opera 5, but seeing as it's very old, it may well have this bug. I have, however, tried Mozilla 1.4, which is closely related to Netscape 7 (though I'm under Windows). It does have this bug. I've reported it to BugZilla: http://bugzilla.mozilla.org/show_bug.cgi?id=213924 So yes, it is very well possible that you are seeing the same bug in two independent browsers. It appears to work fine for me in Opera 7.11 under Windows. Greetings, Timwi

--- Vincent Ramos &lt;siva-nataraja+spam(a)alussinan.org&gt; wrote: Key word : integrist :-) (you said it) <http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&diff=71928&oldid=71914> Yes. Anyone. But then what do you suggest ? To a certain point, I do not care whether you or I are responsible of this. Clearly, our editing ways are incompatible. Still we are on the same place, so we need to find a solution Five solutions 1) a technical explanation and solution is found, and you or I is able to make it up to solve the technical issue 2) You clearly see that I can't do anything to avoid this, so each time you edit a page, and I edit it after you, you go after me without complaining and correct each and other non-breaking space (admitedly, that makes a lot) 3) Each time you write an article, you put your name at the top of the page, and we officially declare I am forbidden to edit this page. Potentially an issue in terms of wiki principle 4) You or I agree to quit wikipedia 5) We do not accept non-breakable spaces on the french wikipedia So ? Does anyone has an idea for option 1 ? Cheers Anthere __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

"Timwi" skribis: I use Cygwin's CVS with SSH-Connection - there you can create your own private key on your computer, and upload the public key to Sourceforge (there is an editbox for this purpose). After that you don't need to type in the password ... Paul

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 July 2003 01:15, Timwi &lt;timwi(a)gmx.net&gt; wrote: Interesting. A quick thought - why not have two-way inter-language links? I can't quite see why we have only one-way links, and one (Dutch?) or more versions of the Wikipedia, people are suggesting running a 'bot to insert them. Also, re. using BLOBs to store images rather than a file system: I would imagine that distributing and clustering a set of databases would be more versatile and easier to accomplish (certainly, I've seen it done in the accessor program's code) than a file system sharing system, which (I imagine) would require work external to the program to set up, and so be messier... - -- James D. Forrester <mailto:jon@eh.org> | <mailto:csvla@dcs.warwick.ac.uk> <mailto:jamesdforrester@hotmail.com> | <mailto:james@jdforrester.org>

I think what James Forrester was saying, about the two-way langa links -- is that in order to put a link from a specific page to another specific page, there must be a 1:1 relationship established. Why not make it so that upon that transaction, the target language page gets a simple reverse tag added to the top of that page? Two birds one stone, I think James was thinking... -S- __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Tomasz Wegrzanowski wrote: While I love c and c++ I must agree. I just really like php and with php5 coming out, we have much to look for in the world of OOP. That and there is so much functionality being added to php all the time, I mean, its not nearly as much as PErl, but its catching up.... Lightning

Lars- I agree quite strongly. One reason behind susning.nu's impressive growth has been the excellent response time of your site. Viewing it almost makes me wish I spoke Swedish, just because it's so pleasant to browse. In fact, Wikipedia initially was very fast, too, thanks to the well written UseMod engine. Too bad it's only file based. Note that Phase III *can* be very fast, too. It is just constantly bogged down by unoptimized queries and slow parsing. Regards, Erik

Timwi- Quite impressive. Let's see how long it takes you to actually implement :-). Some notes: 1) You'll need some capability for banning signed in users. Having bans expire after a while would be nice, too. 2) New message notification needs to work for all users, not just signed in ones. In Phase III we use a table that stores IP addresses of users who have new messages. 3) Currently talk pages and normal pages are "bundled" when watching: You watch one, you also watch the other. You remove one, you remove the other. This behavior should not change. 4) While you're at it, you may want to think about a better access rights system than simple sysop/non-sysop. ACLs would probably work best. As for the userprops, having a langid column seems to make the most sense. Regards, Erik

Timwi- For one thing, we ban offensive usernames. For another, we don't give sysops the ability to view IP addresses of signed in users, so they can't ban their IP because they don't know it. Works for me. Well, the idea is that you can set permissions on a per page basis, and do something like * cannot edit Hans can edit Heinz can edit * can edit Hans cannot edit Heinz cannot edit * can edit anon cannot edit This might be useful for, e.g., allowing certain users to edit the Main Page without giving them sysop privileges. It would also allow use of your engine in other CMS contexts. Might be doable via the articleprops. Regards, Erik

Timwi wrote: did you notice my msg about how to bring special:short and special:long pages back? It's a simple hack but I kinda think its the best way to do this kinda thing data like this should be cached to take work off the db Lightning