subject: [Wikitech-l] Phase IV

body:
Tomasz Wegrzanowski wrote:

>On Fri, Jul 25, 2003 at 10:50:53PM +0200, Magnus Manske wrote:
>
>
>>Well, IMHO you *should* continue if you accept that it might be "just
>>for the fun of it" and never actually used. I learned PHP/MySQL while
>>writing code for Nupedia, which died soon after my code went online (no
>>cause and effect here;-)
>>
>>*If* we decide to work on a Phase IV (one of my favourite movies BTW), I
>>think we should go for C++. Two main reasons:
>>- Probably the fastest way to work with arrays of char (=plain text),
>>which is most of the internal working of a wiki software
>>- Real OOP, in contrast to the PHP-class jokes. If we design a database
>>class in C++, for example, the actual queries could be entirely capsuled
>>from the rest of the program. That would make switching database
>>versions or even databases (MySQL/Postgres/???) much easier.
>>
>>Capsuled classes will also make it easy to write stand-alone-programs
>>for offline reading, as I tried. A proof-of-principle-viewer is
>>available in C++.
>>
>>The main reason *not* to use C++ is that I don't know how to turn such a
>>program into an apache module. Help on that would be appreciated.
>>
>>
>
>Have you lost all self-preservation instinct already ?
>C/C++ is absolutely the most insecure option that exists.
>And if you want to use arrays of chars, you may as well turn off
>the root password - at this point it doesn't really make any different.
>
>If speed was crucial we can use Ocaml, Common Lisp, compiled Java,
>or one of a few other compiled and GC-ed languages with clear separation
>of data and code.
>
>Not to mention that using arrays of chars with hand-written parsers for them
>is almost always slower than naive Perl regular expressions, unless
>parsed language is really trivial, and it's not ever comparable in speed
>to lex+yacc.
>_______________________________________________
>
>
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


list: wikitech-l

source: pipermail-mbox

from_name: Lightning

subject: [Wikitech-l] Re: lastest css changes on test:

body:
Timwi wrote:

> tarquin wrote:
>
>> * links:
>> everyone here seems to hate underlined links.
>
>
> Nooo! Whatever you do, don't remove the underline!! ;-)

my comp sci. teacher is colorblind, if you ask him what he hates most
about the net its non contrasting color schemes and non underlined
links... oh and popups.. but thats a given

Lightning


list: textbook-l

from_name: Daniel Mayer

subject: [Textbook-l] legal counsel on copyright issues

body:
Toby wrote:
>Daniel Mayer wrote:
>
>[nonsense]
>
>Well, mav has pretty obviously not read a single
>word that I've written, so what's the point in replying?
>
>-- Toby

Offlist reply.

--mav


subject: [Textbook-l] different open content licenses

body:
Toby wrote:
>OTOH, the physics and chemistry texts might
>well want to borrow, not just information, but
>entire chunks of text with only minor changes --
>especially given the modular nature of textbooks
>that's been proposed here, where different
>textbooks might share the exact same module.

And how exactly is this going to work if the physics textbook is GNU FDLd and
the chemistry book is CCSA? You cannot mix and match like that because
modules are part of a distinct work. Each work has to be under the same
license.

>I suspect that RMS will accept removing the
>Invariant Sections. But I can't imagine him
>changing the GNU FDL to allow redistribution
>under a Creative Commons license;

If he only removes the invariant sections then the GNU FDL is completely
copyleft and everything major we want it to be. Therefore the differences
between the CCSA and the FDL will be minimal and the advantages of allowing
CCSA along side of the FDL will also be minimal.

>since CC doesn't share the FSF's ethical
>philosophy (they even offer the non-free
>ND and NC license options!),

Strawman alert: The CCSA is the only CC license that could possibly be
compatible with the GNU FDL in both directions.

>how can he be sure that CC licenses will
>remain free?

Simple: "Copyrighted works under the GNU FDL 2.0 or later version created by
the Free Software Foundation can be copied, modified and distributed in full
and placed under the Creative Commons Share Alike license version 2.0 or
later version deemed to be sufficiently free and copyleft per FSF ruling. See
http://www.gnu.org/licenses/fdl/compatibility/ for updates on the status of
the Creative Commons Share Alike license."

>Who has trouble understanding it?

Given the number of copyvios we get daily and the great deal of confusion
people have over copyright issues I would say the answer is self-evident.

>I still expect that most users don't care at all.

And they will furthermore copy text Willy nilly between the various Wikimedia
projects. This should be encouraged. However having incompatible licenses
/within/ Wikimedia will hinder this free exchange.

BTW, we have created over 200,000 encyclopedia articles ourselves and only
occasionally use public domain or GFDL text created elsewhere. There is no
reason to believe that the textbook project will be any different.

Above all else; keep it simple.

-- Daniel Mayer (aka mav)


from_name: Toby Bartels

body:
I wrote:

>Daniel Mayer wrote:

>[nonsense]

>Well, mav has pretty obviously not read a single word that I've written,
>so what's the point in replying?

I apologise to everybody -- and especially to maveric149 --
for the above post.

I will write a better reply to mav's post later on.

-- Toby


from_name: tarquin

subject: [Wikitech-l] kick the server!

body:
could someone kick the server?
en: has come to a complete halt!


list: wikipedia-l

from_name: Richard Grevers

subject: [Wikipedia-l] PNG format???

body:
On Thu, 24 Jul 2003 21:11:07 EDT, <Ralphem at aol.com> gave utterance to the
following:

> Eric,
> There is a basic problem with your logo, logo contest, and use of art in
> general -- a good number of us out here cannot see them! ALL of the art
> on your pages discusssing the logo contest come up with a red X in place
> of the art. You discuss the fact that you want all logo designs in PNG
> format, but this is a format that not all systems (Mac) and not all
> browsers (AOL 5.0, the only software available for older Power PC Macs)
> support -- so you are cutting out a sizeable portion of potential
> viewership.
Are you sure about that? It sounds very strange to me, because for years
Windows users have had to put up with the default viewer for png being
taken over by that most famous piece of cross-platform Appleware,
Quicktime.
And last time I checked out Opera 4 and 5 on my crusty old 75MHz MacpowerPC
it was showing pngs just fine and dandy (except for alpha-transparency,
which came with Opera 6, but you won't find many alpha-transparent PNG's on
the web anyway given that MSIE can't handle them.

--
Richard Grevers
If at first you don't succeed change the rules.


subject: [Wikitech-l] Re: Phase IV

body:
Jens Frank wrote:

>
>Despite this I think wiki software for French Wikipedia
>should be changed to insert  '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.
>
>
It *should* be the web browser that does this!

>
>
>


from_name: Vincent Ramos

subject: [Wikitech-l] Re: Re: Phase IV

body:
Le Fri, 25 Jul 2003 06:25:44 -0700 (PDT), Anthere
<anthere6 at yahoo.com> wrote

> 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.

You should see what other say; for instance Didup, Panoramix (I quote: "Je
suis l'un des integristes de la typographie ici (je mets des vrais
guillemets, des espaces insecables, etc.")), Mokona, etc.

> 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 !)

Well, let me give you a real example:
<http://fr.wikipedia.org/w/wiki.phtml?title=Th%E9_chinois&diff=71928&oldid=71914>
If you had looked at the source with an hexadecimal editor, you could have
seen (first line, from "Note" to ":"):

* my version: 4E 6F 74 65 A0, that is <N>, <o>, <t>, <e> and <[ ]> (non-
breakable space);
* Anthere's version: 4E 6F 74 65 20 ; that is <N>, <o>, <t>, <e>, <[ ]>
(space).

Thus, Anthere made U+00A0 (NBSpace), a normal raw ISO-8859-1 character,
become U+0020, the normal space.

Anyone can verify this fact

Vincent Ramos


subject: [Wikitech-l] Re: Phase IV

references: <bfplrs$gdr$1@main.gmane.org> <3F20614B.8060707@chaos-productions.com> <bfpqs9$86h$1@main.gmane.org> <20030725193551.GG1945@jeluf.mine.nu> <bfs6la$181$1@main.gmane.org> <3F21A32D.3010904@chaos-productions.com> <bfsbbh$r6d$1@main.gmane.org>

body:
> if ($url !~ m!^(\w+)://((?:\w+\.)*\w+)(?::(\d+))(/.*)$!) {

Since when are we censoring curse words on the list??

Lightning


subject: [Wikitech-l] Re: Re: Phase IV

body:
Le Fri, 25 Jul 2003 08:22:02 -0700 (PDT), Anthere
<anthere6 at yahoo.com> a ?crit:

> 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.

I've just told you how you could do this; rather simple but daunting.

> 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 :-((((

What kind of behavior is this? Will you then start crying?

> 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

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.

> This desolate me, but if the consensus is to make
> editing difficult, I can only try to salvage my little
> area of edition.

> Ah, yes, he absolutely does so. Word processor.

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.

> 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 !
> :-(((((( !!!!!

Frankly, I find this really childish.

> 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 ???

Nope.

>> is quite obvious that your edits did not break
>> anything because the   s Vincent added were still there after your
>> further edits to the  same page.

Of course: Anthere only modifies U+00A0, and not html entities.

> 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.

No.


from_name: Jens Frank

subject: [Wikitech-l] Re: Phase IV

body:
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


subject: [Wikitech-l] Re: The New French Editor, was Re: Phase IV

body:
Le Fri, 25 Jul 2003 09:47:08 -0600, Fred Bauder
<fredbaud at ctelco.net> wrote:

> Well, you've got to bring it to a head. Pick something of his and edit
> it.

Thanks.

> And fight it out. Otherwise you're letting him establish a custom and
> practice that in the long run is unacceptable. Basically he is what we
> used to call "taking position" on you. More or less in the manner of
> Larry
> Sanger.

You really should not try to judge people without knowing what they have to
say.

> Let him worry about the anchors...just bull ahead...
> That you are in essence poking what seems to be a skunk, albeit a pretty
> French one, will tell you the sacrifices you must bear...

Bravo. That's a kind of incisive judgement I find rather displaced: when
one only knows what another one tells about someone (did you ever think
Anthere could be wrong?) and takes it for granted whithout even verifiying
the facts.

> The alternative is to permit him ownership of the article, an option not
> permitted by current Wikipedia policy (although I don't happen to be in
> agreement with it).

I've *never* asked this. And whoever can modify the pages I wrote.


subject: [Wikitech-l] Re: Phase IV

body:
On Fri, Jul 25, 2003 at 12:15:35PM -0700, Anthere wrote:
>
> --- Erik Moeller <erik_moeller at gmx.de> wrote:
>
> Vincent replied the example chosen was not good
>
> I tried to translate his comment below
>
> :* anterior version : 4E 6F 74 65 A0, which
> corresponds with ''N'', ''o'', ''t'', ''e'', ''[ ]
> (non breakable space)'' ;
> :* corrected version : 4E 6F 74 65 20 ; which
> corresponds with ''N'', ''o'', ''t'', ''e'', ''[ ]
> (normal space)''.
>
> --------
>
> Anthere : so ? :-(
>
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  '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


subject: [Wikitech-l] lastest css changes on test:

body:
some of these are really gross.

* tiny headers.
with the amount of junk above the page header, it's even harder for the
casual reader to *find the article title*. This must be made bigger
UNTIL we redesign the skin (any news on this? I've more or less given up
due to a) lack of interest and b) the threat of a vote. should I do more
work on this?)
* links:
everyone here seems to hate underlined links. Fair enough. But it would
be nice to add an underline on the hover pseudoclass.

I'll make these changes unless people object.

Another thing I would like to change is this:

Our code currently puts

<body bgcolor='#FFFFFF'>

for system pages.
It would be more elegant (and more compliant) to do this:

<body class="meta">
or
<body class="encyclopedia">

and then put two rules in the stylesheet.
This would also allow skins to make other changes to distinguish between
article & meta -- someone suggested italic headers for meta a long time ago.
I can *probably* work out how to do this in PHP. But if someone is
available to help me with this, please let me know!


subject: [Wikitech-l] Re: Re: Phase IV

body:
On Fri, Jul 25, 2003 at 09:30:18PM +0200, Vincent Ramos wrote:
> Le Fri, 25 Jul 2003 08:22:02 -0700 (PDT), Anthere
> <anthere6 at yahoo.com> a ???crit:
>
>
> >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 :-((((
>
> What kind of behavior is this? Will you then start crying?
>
Vincent, I doubt that your behaviour is acceptable by any
means.

Regards,

	JeLuF


subject: [Wikitech-l] Re: Phase IV

body:
On Fri, Jul 25, 2003 at 08:55:23PM +0100, tarquin wrote:
>
>
> Jens Frank wrote:
>
> >
> >Despite this I think wiki software for French Wikipedia
> >should be changed to insert  '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.
> >
> >
> It *should* be the web browser that does this!
>
Agreed, but I think it might be easier to update
wikipedia software than all available browsers.

JeLuF


body:
Le Fri, 25 Jul 2003 11:45:05 -0700 (PDT), Anthere
<anthere6 at yahoo.com> wrote:

> 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 !

It's a shame! I never wrote that; just look at the history. The text is
even not well written (lacks a capital, does not use the right quote marks,
etc.). Frankly, this is disgusting and, there, you are making a forgery. I
can not believe you think *I* wrote this.

> 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"

Yes, because, as I've already told, it's rather boring to do I do know
where the links are.


body:
Toby wrote:
>I apologise to everybody -- and especially to
>maveric149 -- for the above post.

Apology accepted and no hard feelings. :-)

WikiLove

--mav


from_name: Magnus Manske

subject: [Wikitech-l] Phase IV

body:
Well, IMHO you *should* continue if you accept that it might be "just
for the fun of it" and never actually used. I learned PHP/MySQL while
writing code for Nupedia, which died soon after my code went online (no
cause and effect here;-)

*If* we decide to work on a Phase IV (one of my favourite movies BTW), I
think we should go for C++. Two main reasons:
- Probably the fastest way to work with arrays of char (=plain text),
which is most of the internal working of a wiki software
- Real OOP, in contrast to the PHP-class jokes. If we design a database
class in C++, for example, the actual queries could be entirely capsuled
from the rest of the program. That would make switching database
versions or even databases (MySQL/Postgres/???) much easier.

Capsuled classes will also make it easy to write stand-alone-programs
for offline reading, as I tried. A proof-of-principle-viewer is
available in C++.

The main reason *not* to use C++ is that I don't know how to turn such a
program into an apache module. Help on that would be appreciated.

Magnus

Timwi wrote:
>
> Hi,
>
> the past few days I've been experimenting a bit with Apache, mod_perl,
> MySQL and creating an entire own website. I've never done that before,
> and I think I've learnt a lot from this.
>
> Now, for some reason, against all of your advice, I have started to
> program a Wiki, and by now it's already become a suitable basis for a
> Phase-IV Wikipedia software, including a database schema.
>
> It really doesn't seem to be very difficult to re-program the current
> software in Perl, this time taking all the problems into account and
> designing everything right from the start (incl. single-login,
> multi-language watchlists, a better translation system and skin system
> (separated from the code), etc.) I've also made a lot of considerations
> and decisions with respect to database design and performance.
>
> Should I continue with this?
>
> Greetings,
> Timwi
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Phase IV

body:
On Fri, Jul 25, 2003 at 10:50:53PM +0200, Magnus Manske wrote:
> Well, IMHO you *should* continue if you accept that it might be "just
> for the fun of it" and never actually used. I learned PHP/MySQL while
> writing code for Nupedia, which died soon after my code went online (no
> cause and effect here;-)
>
> *If* we decide to work on a Phase IV (one of my favourite movies BTW), I
> think we should go for C++. Two main reasons:
> - Probably the fastest way to work with arrays of char (=plain text),
> which is most of the internal working of a wiki software
> - Real OOP, in contrast to the PHP-class jokes. If we design a database
> class in C++, for example, the actual queries could be entirely capsuled
> from the rest of the program. That would make switching database
> versions or even databases (MySQL/Postgres/???) much easier.
>
> Capsuled classes will also make it easy to write stand-alone-programs
> for offline reading, as I tried. A proof-of-principle-viewer is
> available in C++.
>
> The main reason *not* to use C++ is that I don't know how to turn such a
> program into an apache module. Help on that would be appreciated.

Have you lost all self-preservation instinct already ?
C/C++ is absolutely the most insecure option that exists.
And if you want to use arrays of chars, you may as well turn off
the root password - at this point it doesn't really make any different.

If speed was crucial we can use Ocaml, Common Lisp, compiled Java,
or one of a few other compiled and GC-ed languages with clear separation
of data and code.

Not to mention that using arrays of chars with hand-written parsers for them
is almost always slower than naive Perl regular expressions, unless
parsed language is really trivial, and it's not ever comparable in speed
to lex+yacc.


from_name: Timwi

subject: [Wikitech-l] Re: Phase IV

body:
Jens Frank wrote:

> 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.

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.)

> does it allow e.g. a design of
> Recent Changes as a big array?

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.

> 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.

I'm not exactly sure what you mean here by a 'journal' if not a
dedicated database table?

>>>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.

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 don't think the database schema is the source of our problems, I thinks
> it's the RDBMS.

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.

>>I haven't used $? yet :)))
>
> I suddenly remember why I don't like Perl ...

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


subject: [Wikitech-l] Re: Phase IV

body:
Erik Moeller wrote:

> Timwi-
>
> You definitely should use a CVS server if you expect any kind of
> constructive contributions.

Yes, I know :/ Thanks for your hints, but I think I'll stick to
SourceForge just to go with the majority.

>>>* have some kind of built in profiling
>>What exactly does this mean?
> Keep a log of how much time is spent within each function

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.

> Categories will likely go live soon (if Magnus finally finishes the damn
> thing), so a compatible scheme needs to be in place if we want to switch
> over.

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.

>>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 never understood this approach. It only seems to be associated with
> increased risks (reduced performance, increased risk of data corruption)
> and have no benefits. What exactly is the disadvantage of just storing a
> pointer to the local filesystem in the DB?

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.

>>>* have a template system that can be used by the wiki user:
>>>http://marc.theaimsgroup.com/?l=wikitech-l&m=105557077500936&w=2
>>>this could perhaps be combined with the general template system.
>
>>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.
>
> I do think there are similarities between the two. Any good template
> system, for site skins OR for internal rendering, will have to support
> things like loops, conditional blocks etc. This stuff needs to be parsed,
> so you might as well use a single library for doing so.

You have convinced me about this. I'll try to combine the two.

> You are using proper object-oriented design, I hope?

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


subject: [Wikitech-l] Non-breaking spaces and browser bugs

body:
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:

> So...the same problem is occuring under Opera 5 and
> Netscape 7. Vincent claims it is my browser. So these
> are my browserS. Or my system. Or my plateform. Or
> what ?

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


subject: [Wikitech-l] Re: Phase IV

body:
Magnus Manske wrote:

> *If* we decide to work on a Phase IV (one of my favourite movies BTW), I
> think we should go for C++. Two main reasons:
> - Probably the fastest way to work with arrays of char (=plain text),
> which is most of the internal working of a wiki software

Although you're probably right that C++ is very fast in terms of
handling of character arrays, I'm not sure this miniscule speed benefit
rectifies using a language that isn't UTF-8 aware. Perl 5.8 onwards
understands UTF-8 and can work with it internally, i.e. in its own C
code, so it shouldn't be significantly slower.

> - Real OOP, in contrast to the PHP-class jokes.

That would be one reason I would greatly agree with you.

> The main reason *not* to use C++ is that I don't know how to turn such a
> program into an apache module. Help on that would be appreciated.

I don't know that either. The only two ways of using a compiled binary
in Apache that I know of would be either to set it as a handler for a
filename extension, or to call it using CGI. Both methods are
inacceptable because they create a new process for each HTTP request.

I've never heard of other web software written in C++ (apart from the
*actual* webserver, Apache, of course). Not that I mind Wikipedia being
an oddball in that respect, but if nobody did this before, maybe that's
a sign it might not be a good idea.

Maybe we should write a whole new webserver (just joking).

Timwi


body:
tarquin wrote:

> * links:
> everyone here seems to hate underlined links.

Nooo! Whatever you do, don't remove the underline!! ;-)

Of course, I'm exaggerating; I don't want to start another religious war
about this. But I'm in favour of underlines. I have mentioned before
that I have somewhat handicapped vision; I like to be able to see from
first glance what is a link and what isn't. I know you're planning to
make them a different colour... while that makes them stick out as you
read the text, it doesn't really make them stick out when you only skim
the page or even just plain look at it without focussing on any text.

And most of all, the underline shows whether two words are separate
links or not. Since I hardly ever use the mouse, the hover effect
wouldn't help me. Pretend I had some sort of disability that prevents me
from using the mouse at all, and then think in terms of accessibility :)

I am also in favour of the underlined headings, but I think that idea is
shot down already.

> Another thing I would like to change is this:
> Our code currently puts <body bgcolor='#FFFFFF'> for system pages.

Oooh yes! This irked me when I saw it, although it doesn't really affect
my experience of Wikipedia.

> I can *probably* work out how to do this in PHP.

You don't need to know any PHP for this. If you just search all the
files for 'ffffff', you find Skin.php, Line 124. I'll quote Lines 121-124:

		if ( 0 != $wgTitle->getNamespace() ) {
			$a = array( "bgcolor" => "#FFFFDD" );
		}
		else $a = array( "bgcolor" => "#FFFFFF" );

Clearly, these are the background colours for meta-namespaces and the
article namespace. Seeing as 'ondblclick' and 'onload' are also used in
the same routine, you can probably safely change this to

		if ( 0 != $wgTitle->getNamespace() ) {
			$a = array( "class" => "meta" );
		}
		else $a = array( "class" => "encyclopedia" );

Have I ever mentioned that I find 'encyclopedia' to be an incredibly
hard word to type?

Greetings,
Timwi


subject: [Wikitech-l] Re: Phase IV

body:
Lightning wrote:

> I mean I love php, i just do and i just dont like Perl cause i never
> did understand it to well..

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. :)

> But as I said, I have a hard time reading perl..

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.

> oh and i wont even look at regexps..

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


list: wikien-l

from_name: james duffy

subject: [WikiEN-l] Erik's rewriting of policy pages unilaterally

body:
>Daniel-
> > An editor /cannot/ unilaterally change policy.

Erik wrote
>An editor (everyone is an editor on Wikipedia, so you might as well say "a
>user") can change policy pages if there are no objections to them doing
>so. They should use common sense to determine whether their change would
>require prior discussions, or be reasonably minor or non-controversial not
>to. The same principle applies to edits of non-policy pages. Be bold in
>updating policy pages.

Actually people /don't/ do that without discussing ideas first on the talk
page. If it is a proposed /major/ change it is put on the wiki-list. What
they don't do is unilaterally make major changes without making sure people
know the change is being made. Otherwise it looks like the page is being
highjacked in the hope that no-one will notice that policy is being changed.
And if no-one notices on time, then if anyone tries to use the 'old'
/agreed/  policy finds them being told - "oh but we changed that a while
ago". That is clearly unfair and disrespectful of everyone else.

When I've proposed changes, I've put them on the talk page, left a message
on the talk page of everyone who had ever contributed to the talk page
debates asking their views, and left a summary message that would appear on
the recent changes, saying a proposed change was being made and asking
anyone interest to comment on the talk page. /If/ there was agreement that
the proposal should be implemented, I then put together a formal wording
taking account people's observations, then showed it to people to make sure
there was a consensus on it. Only /then/ was it put on the actual page.
Where I made a minor change, or sought to clarify something whose meaning
was unclear in the actual wording but where what it was meant to be was
clear in the discussion, I'd contact those who took part in the debate and
invite them to review the change, and would explain the change on the
summary with an invitation for anyone who wished to review it.  Just
bulldozing ahead with changes without a full and frank debate is I believe
disrepectful to all wikipedians and highjacking a page.

I am surprised and more than a little disappointed to find that Erik, whom I
have always respected notwithstanding our disagreements, thinks it OK just
to unilaterally rewrite policy pages when he feels like it. It makes me
wonder how many times have rows where Erik has criticised some member for
'not following the rules' really been a case of people breaking 'new' rules
Erik had created and which had never been noticed until it was too late,
everyone presuming that if it in the rules, it must have been agreed after a
full discussion that they simply missed, not Erik's own invention.

JT

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail


subject: [WikiEN-l] Daniel C. Boyer on wikipedia

body:
> > The Daniel C. Boyer bandwagon is getting a bit out of control. Daniel is
>a
> > user on wiki who has an article about himself on wiki. While that seems
>OK
> > as he is a real if rather minor celebrity and artist, his articles
>relating
> > to himself are breeding like rabbits.

The Cunctator wrote

>I fail to see the problem. Wikipedia is meant to be a universal
>encyclopedia.

Once Daniel don't interpret universal as universally about him! :-)

JT

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus


from_name: Hunter Peress

subject: [Wikitech-l] Re: Phase IV

body:
>Timwi-
>> 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.

Python has a profiling module. See an example which i used to find bottlenecks in the
bittorrent code: http://24.175.39.66/~hperes/btdh_upload_only_XP1800_20minutes_runtime.txt

>
>Well, that's not necessarily true. CPU usage on Larousse (the webserver
>for En:) has been very high, and our page parser is very ugly and slow.
>Clearly we need optimizations on both fronts.

Python has an amazing JIT/code optimizer named psyco (psyco.sf.net). Most
text processing type operations are sped up to the level of pure C. I
wrote a difflib module (almost identitical to our difflib.php here) in C/python
api and psyco (when run on the pure python version) met it's performance.

>> 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.
>>
>Well, then test it. Throw some 10 megabyte files into the database and
>compare the reading performance with multiple threads to direct Apache
>server access.

YES. test,test,test. This is the precept of extreme (and proper) programming.

>Perl-OOP is a bit ugly, but reasonably powerful. Check out perldoc
>perltoot for details. You'll want to look at "tie" especially, as this
>allows you to do some cool stuff with properties.

Mainly its just ugly. Perl is a horrible language whose time has passed. Its number
one bad feature is confusion. Perl allows more unmaintainable and entropic code
than most any language except brainfuck. It's development is pathetic over the last few
years, the language and community have no focus.

Python is a language that is only 1 year younger than perl (1990). Its had threads since
the beginning, whereas perl just obtained them last year for example... Python has no bad
features, in that it only allows for low entropy code. It has a rich standard library, and is
accepted widely.
Read this oreilley publication http://www.onlamp.com/pub/wlg/3198 which covers 8 stories in big
industry (industrial-light-and-magic ILM for example) and how after years of working with things
python is the number 1 language of choice over php, perl, c, java, lisp.

There is a great wiki written in python, called moin moin, its filed based even, not database
based, and i believe that this avenue is more lightweight and deserves some consideration.
Yes...ive followed all wikipedia's static-file "to cache or not to cache arguments...".

There are great idioms and frameworks out there to make content management and web publishing
low-entropy and maximally effective.

Namely: zope's cmf: http://cmf.zope.org/
AND  twisted.woven: http://twistedmatrix.com/documents/howto/woven
and of course...mod_python which is in-apache.

Heck...this wikitech mailing list (list.org)  is written in python.

google, yahoo , various goverments accross the world all prefer python. Dynamically typed
langauages
like perl, python, and php are far more productive than anally typed java/ocaml. And archaic
langauges like c++, c, fortan.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Anthere

subject: [Wikitech-l] Re: The New French Editor and edit war

body:
Me too :-)

I made some of the changes about which I talked about

Consisting in major part of dividing the 48 kb page
into two new pages.

Vincent has restored everything, declared an edit war,
and ask for the page to be protected.

Ownership you said ?

:-)

--- Fred Bauder <fredbaud at ctelco.net> wrote:
> Good to know it was all a false alarm...
>
> Fred Bauder
>
> http://www.internet-encyclopedia.org
>
> > From: Vincent Ramos
> <siva-nataraja+spam at alussinan.org>
> > Organization: Les Dieux anciens r?unis
> > Reply-To: wikitech-l at wikipedia.org
> > Date: Fri, 25 Jul 2003 21:36:30 +0200
> > To: wikitech-l at wikipedia.org
> > Subject: [Wikitech-l] Re: The New French Editor,
> was Re: Phase IV
> >
> > Le Fri, 25 Jul 2003 09:47:08 -0600, Fred Bauder
> > <fredbaud at ctelco.net> wrote:
> >
> >> Well, you've got to bring it to a head. Pick
> something of his and edit
> >> it.
> >
> > Thanks.
> >
> >> And fight it out. Otherwise you're letting him
> establish a custom and
> >> practice that in the long run is unacceptable.
> Basically he is what we
> >> used to call "taking position" on you. More or
> less in the manner of
> >> Larry
> >> Sanger.
> >
> > You really should not try to judge people without
> knowing what they have to
> > say.
> >
> >> Let him worry about the anchors...just bull
> ahead...
> >> That you are in essence poking what seems to be a
> skunk, albeit a pretty
> >> French one, will tell you the sacrifices you must
> bear...
> >
> > Bravo. That's a kind of incisive judgement I find
> rather displaced: when
> > one only knows what another one tells about
> someone (did you ever think
> > Anthere could be wrong?) and takes it for granted
> whithout even verifiying
> > the facts.
> >
> >> The alternative is to permit him ownership of the
> article, an option not
> >> permitted by current Wikipedia policy (although I
> don't happen to be in
> >> agreement with it).
> >
> > I've *never* asked this. And whoever can modify
> the pages I wrote.
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikipedia.org
> >
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [Wikitech-l] Re: Phase IV

body:
Erik Moeller wrote:
> Timwi-
>
> The current documentation of your database schema is completely
> insufficient, though. Each table needs its own comment header explaining
> what it does, how and why.

Something like this?
http://www.lionking.org/~timwi/t/wikipedia/wikipedia-iv.html

Timwi


subject: [Wikitech-l] Re: Phase IV

body:
I've uploaded the following file to demonstrate... something... or just
to show off, I don't know...

http://www.lionking.org/~timwi/t/wikipedia/wikipedia-iv.html

Well, basically, there are some questions and options left, and I would
appreciate any feedback and discussion. For example, how would we handle
language-specific user properties (read the paragraph underneath the
'user properties' heading)? etc.

Thanks,
Timwi


subject: [Textbook-l] request Admin status

body:
It would be nice to be able to move pages - so to any developer out there; Can
I be an Admin for the textbook project?

How active does a wiki have to be to make 'move this page' a non-Admin option?
Just wondering - no real biggie.

-- Daniel Mayer (user:maveric149 internal ID #7)


subject: [Wikitech-l] request Admin status


body:
--- Fred Bauder <fredbaud at ctelco.net> wrote:
> 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
>
> > From: Anthere <anthere6 at yahoo.com>
> > Reply-To: wikitech-l at wikipedia.org
> > Date: Sat, 26 Jul 2003 02:07:02 -0700 (PDT)
> > To: wikitech-l at wikipedia.org
> > Subject: Re: [Wikitech-l] Re: The New French
> Editor and edit war
> >
> > Me too :-)
> >
> > I made some of the changes about which I talked
> about
> >
> > Consisting in major part of dividing the 48 kb
> page
> > into two new pages.
> >
> > Vincent has restored everything, declared an edit
> war,
> > and ask for the page to be protected.
> >
> > Ownership you said ?
> >
> > :-)
> >
> >
> > --- Fred Bauder <fredbaud at ctelco.net> wrote:
> >> Good to know it was all a false alarm...
> >>
> >> Fred Bauder
> >>
> >> http://www.internet-encyclopedia.org
> >>
> >>> From: Vincent Ramos
> >> <siva-nataraja+spam at alussinan.org>
> >>> Organization: Les Dieux anciens r?unis
> >>> Reply-To: wikitech-l at wikipedia.org
> >>> Date: Fri, 25 Jul 2003 21:36:30 +0200
> >>> To: wikitech-l at wikipedia.org
> >>> Subject: [Wikitech-l] Re: The New French Editor,
> >> was Re: Phase IV
> >>>
> >>> Le Fri, 25 Jul 2003 09:47:08 -0600, Fred Bauder
> >>> <fredbaud at ctelco.net> wrote:
> >>>
> >>>> Well, you've got to bring it to a head. Pick
> >> something of his and edit
> >>>> it.
> >>>
> >>> Thanks.
> >>>
> >>>> And fight it out. Otherwise you're letting him
> >> establish a custom and
> >>>> practice that in the long run is unacceptable.
> >> Basically he is what we
> >>>> used to call "taking position" on you. More or
> >> less in the manner of
> >>>> Larry
> >>>> Sanger.
> >>>
> >>> You really should not try to judge people
> without
> >> knowing what they have to
> >>> say.
> >>>
> >>>> Let him worry about the anchors...just bull
> >> ahead...
> >>>> That you are in essence poking what seems to be
> a
> >> skunk, albeit a pretty
> >>>> French one, will tell you the sacrifices you
> must
> >> bear...
> >>>
> >>> Bravo. That's a kind of incisive judgement I
> find
> >> rather displaced: when
> >>> one only knows what another one tells about
> >> someone (did you ever think
> >>> Anthere could be wrong?) and takes it for
> granted
> >> whithout even verifiying
> >>> the facts.
> >>>
> >>>> The alternative is to permit him ownership of
> the
> >> article, an option not
> >>>> permitted by current Wikipedia policy (although
> I
> >> don't happen to be in
> >>>> agreement with it).
> >>>
> >>> I've *never* asked this. And whoever can modify
> >> the pages I wrote.

I feel like choking Fred....

After several reversion (I should mention that I made
a couple of light (non controversial) edits to the
resulting articles (headings, better titles, links and
such), so I would not really appreciate that my
changes  are removed just because we disagree on the
division of the page.

The last comment put in the comment box by Vincent
while reverting was

----- his comment

Dernier avertissement. Ensuite, je serais d?sol? de le
faire, mais apposerai mon copyright sur cette page
(les documents m'attribuant la paternit? de son
contenu ?tant ? c?t? de moi).

----which means

Last warning. Next time, I will be sorry to do it, but
I will add my copyright on this page (the documents I
have just next to me attribute me the paternity of its
content)

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Lars Aronsson

subject: [Wikitech-l] Re: Phase IV

body:
Timwi wrote:
> I've uploaded the following file to demonstrate... something... or just
> to show off, I don't know...
>
> http://www.lionking.org/~timwi/t/wikipedia/wikipedia-iv.html

You forgot one parameter: Response time.  As far as I know, phase III
doesn't even have a design goal for response time, only a naive hope
that it will be "as fast as possible", which in reality for the last
week seems to be an average of 1.5 seconds, with 8% of requests taking
more than 5 seconds.  It has been far worse at times.

I think that phase IV should have a design goal for response times,
and that your specification should outline a way to monitor them and
keep them within the goal.  I suggest setting a goal for the average
of 1.0 seconds and no more than 1% should take more than 5 seconds.

In my experience, it is slow response times that make users leave a
website never to return again.  Lack of features or ugly design isn't
half as bad.

A way to measure churn (the rate at which users abandon the site)
would also be nice.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


from_name: Fred Bauder

body:
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

> From: Anthere <anthere6 at yahoo.com>
> Reply-To: wikitech-l at wikipedia.org
> Date: Sat, 26 Jul 2003 02:07:02 -0700 (PDT)
> To: wikitech-l at wikipedia.org
> Subject: Re: [Wikitech-l] Re: The New French Editor and edit war
>
> Me too :-)
>
> I made some of the changes about which I talked about
>
> Consisting in major part of dividing the 48 kb page
> into two new pages.
>
> Vincent has restored everything, declared an edit war,
> and ask for the page to be protected.
>
> Ownership you said ?
>
> :-)
>
>
> --- Fred Bauder <fredbaud at ctelco.net> wrote:
>> Good to know it was all a false alarm...
>>
>> Fred Bauder
>>
>> http://www.internet-encyclopedia.org
>>
>>> From: Vincent Ramos
>> <siva-nataraja+spam at alussinan.org>
>>> Organization: Les Dieux anciens r?unis
>>> Reply-To: wikitech-l at wikipedia.org
>>> Date: Fri, 25 Jul 2003 21:36:30 +0200
>>> To: wikitech-l at wikipedia.org
>>> Subject: [Wikitech-l] Re: The New French Editor,
>> was Re: Phase IV
>>>
>>> Le Fri, 25 Jul 2003 09:47:08 -0600, Fred Bauder
>>> <fredbaud at ctelco.net> wrote:
>>>
>>>> Well, you've got to bring it to a head. Pick
>> something of his and edit
>>>> it.
>>>
>>> Thanks.
>>>
>>>> And fight it out. Otherwise you're letting him
>> establish a custom and
>>>> practice that in the long run is unacceptable.
>> Basically he is what we
>>>> used to call "taking position" on you. More or
>> less in the manner of
>>>> Larry
>>>> Sanger.
>>>
>>> You really should not try to judge people without
>> knowing what they have to
>>> say.
>>>
>>>> Let him worry about the anchors...just bull
>> ahead...
>>>> That you are in essence poking what seems to be a
>> skunk, albeit a pretty
>>>> French one, will tell you the sacrifices you must
>> bear...
>>>
>>> Bravo. That's a kind of incisive judgement I find
>> rather displaced: when
>>> one only knows what another one tells about
>> someone (did you ever think
>>> Anthere could be wrong?) and takes it for granted
>> whithout even verifiying
>>> the facts.
>>>
>>>> The alternative is to permit him ownership of the
>> article, an option not
>>>> permitted by current Wikipedia policy (although I
>> don't happen to be in
>>>> agreement with it).
>>>
>>> I've *never* asked this. And whoever can modify
>> the pages I wrote.
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l at wikipedia.org
>>>
>>
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at wikipedia.org
>>
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


body:
Yes, one of my grave defects is love of stirring up trouble.

Vincint,

I hope you can see, apart from the fun we are having, that anyone who logs
on to the French Wikipedia, not just Anthere, can edit your article. I
sympathise with your view that you should be able to maintain the integrity
of your article and in most publishing situations you could, (like fun) but
where you are you can't due to the GNU copyright (which by publishing on
Wikipedia you have implicitly agreed to). I hope this clarifies the
situation.

Fred Bauder

http://www.internet-encyclopedia.org

> From: Anthere <anthere6 at yahoo.com>
> Reply-To: wikitech-l at wikipedia.org
> Date: Sat, 26 Jul 2003 03:09:37 -0700 (PDT)
> To: wikitech-l at wikipedia.org
> Subject: Re: [Wikitech-l] Re: The New French Editor and edit war
>
>
> --- Fred Bauder <fredbaud at ctelco.net> wrote:
>> 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

>
> I feel like choking Fred....
>
> After several reversion (I should mention that I made
> a couple of light (non controversial) edits to the
> resulting articles (headings, better titles, links and
> such), so I would not really appreciate that my
> changes  are removed just because we disagree on the
> division of the page.
>
> The last comment put in the comment box by Vincent
> while reverting was
>
> ----- his comment
>
> Dernier avertissement. Ensuite, je serais d?sol? de le
> faire, mais apposerai mon copyright sur cette page
> (les documents m'attribuant la paternit? de son
> contenu ?tant ? c?t? de moi).
>
> ----which means
>
> Last warning. Next time, I will be sorry to do it, but
> I will add my copyright on this page (the documents I
> have just next to me attribute me the paternity of its
> content)
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


subject: [Textbook-l] request Admin status

body:
Erik wrote:
>You don't need to be admin to move pages,
>you just need to be logged in. Do you still want
>to be admin?

Yep - you are right. The fact that the Admin interface has "Delete this page |
Protect this page | Move this page" on the bottom threw me since "Move this
page" is not on the bottom on the standard user skin (failing to see that I
didn't even look at the sidebar).

But yeah - why not? At the very least I'll get the "Move this page" link where
I'm used to having it. ;-) I suggest Karl Wick also be an Admin (if he isn't
already) since he is the most active person right now and hence the person
most likely to notice vandalism before anybody else.

-- mav


from_name: Axel Boldt

subject: [WikiEN-l] 172 sysop status temporarily revoked

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:

> I am very sensitive to these matters, and if you feel that I am the
> wrong person to do this, I will gladly stop handling the sysop
> requests on Wikipedia.

I am thankful for your handling sysop requests on Wikipedia. This does
not include your unsysoping people with whom you had a conflict,
without prior discussion on this list.

> I also encourage you to set up an
> alternative process page that does not rely on an individual user,
> such as "Votes for unsysopping".

I don't see the need for such a page and indeed find it
counterproductive. The extremely rare requests for unsysoping can and
should be discussed here on the list.

Axel

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Erik Moeller

body:
james-

>> Daniel-
>>> An editor /cannot/ unilaterally change policy.

> Erik wrote
>> An editor (everyone is an editor on Wikipedia, so you might as well say "a
>> user") can change policy pages if there are no objections to them doing
>> so. They should use common sense to determine whether their change would
>> require prior discussions, or be reasonably minor or non-controversial not
>> to. The same principle applies to edits of non-policy pages. Be bold in
>> updating policy pages.

> Actually people /don't/ do that without discussing ideas first on the talk
> page.

Look, James, I know that it's fun slandering me, but I would appreciate it
if you could stop for a second and actually read what I wrote. Thanks.

Regards,

Erik


subject: [Textbook-l] No new wikis

body:
Toby-
>> Anyone is of course free to start their own project on their own servers,
>> but a Wikimedia brand project should have support from a substantial
>> number of, er, Wikimedians. We're not a wiki hosting provider.

> Since when does Wikimedia take votes to make these decisions?

We never did. I proposed that we should start.

> A substantial number of Wikimedians /does/ want to do Wikibooks.

Certainly.

> I don't need any vote to prove this.

A vote would help to determine if there are many Wikimedians who are
against the project. I would have voted against the Wikibook project in
its present "Textbook" form, for example. There are many projects where
there will be dissent among Wikimedians on whether they should be operated
by Wikimedia or not. Take POV projects like Disinfopedia, for example --
I'm sure there are many Wikimedians who like the idea and would love it to
run under the Wikimedia banner. But many others would be against this,
either because they see NPOV violated, or because they see *their* POV
violated.

In that case, it would not be enough to simply say "Look, it's quite
obvious that many people want this, so quit yer whining already." A
formalized voting process after the project plan has been finalized helps
to address such concerns, and makes sure that a large number of
Wikimedians is exposed to every new idea -- if not in the planning phase,
then in the voting phase -- and gets a fair chance to voice their dissent.

The alternative would be to let Jimbo decide in each individual case.

Regards,

Erik


subject: [Wikitech-l] Re: Phase IV

body:
Timwi-
> 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.

Well, that's not necessarily true. CPU usage on Larousse (the webserver
for En:) has been very high, and our page parser is very ugly and slow.
Clearly we need optimizations on both fronts.

Please do take a look at the Wookee parser module that Tarquin pointed to.
It uses a syntax very similar to Wikipedia's.
http://wiki.beyondunreal.com/wiki/Wookee

> 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.

Sure. And if it's a decent wiki, you can add it to
http://c2.com/cgi/wiki?WikiEngines
and hope that people use it for other purposes.

>>> I think it's better to store them in a database, possibly one
>>> separated from the rest.

>> I never understood this approach. It only seems to be associated with
>> increased risks (reduced performance, increased risk of data corruption)
>> and have no benefits. What exactly is the disadvantage of just storing a
>> pointer to the local filesystem in the DB?

> 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.

Not necessarily. But if the database file is corrupted, the database may
no longer process the table correctly, in which case the binary data would
have to be hand-extracted to rescue it. If you see the database as another
layer on top of the file system, and argue that the same risks apply to
the DB as to the filesystem, then you have doubled your risks by adding a
DB layer. You would triple them by adding a database within the database,
and so on. (We actually have done this with the Wikipedia table structure,
where user properties are a kind of CSV table within the database. Really
ugly.)

> 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.

Well, then test it. Throw some 10 megabyte files into the database and
compare the reading performance with multiple threads to direct Apache
server access.

> 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.

Sure, but given that you only have to deal with create, move, delete
implementation complexity is minimal, and the associated risks should be
low. In addition, I *like* being able to just zip the entire image
directory instead of having to extract the files from a MySQL table.

> 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 :)

Perl-OOP is a bit ugly, but reasonably powerful. Check out perldoc
perltoot for details. You'll want to look at "tie" especially, as this
allows you to do some cool stuff with properties.

Regards,

Erik


subject: [Wikitech-l] Re: Non-breaking spaces

body:
Vincent-
> Of course: Anthere only modifies U+00A0, and not html entities.

Then don't use U+00A0 -- Anthere uses a reasonably modern browser, and if
this bug happens in two constellations (Opera + Netscape 7), she will not
be the only one to break these spaces. Use   or don't use hard spaces
at all.

Regards,

Erik


body:
Why don't you start by forwarding this post to X privately using the link on
his user page if he has one.

Fred Bauder

http://www.internet-encyclopedia.org

> From: <viajero at quilombo.nl>
> Reply-To: wikien-l at wikipedia.org
> Date: Sat, 26 Jul 2003 13:58:00 +0200 (CEST)
> To: <wikien-l at wikipedia.org>
> Subject: [WikiEN-l] Wikipedia: Warehouse or Pyramid?
>
> Hi all,
>
> I am fairly new to Wikipedia and I would like to ask the advice of some
> of the more experienced wikipidians.
>
> To begin with, I am impressed with the high quality of the writing of
> some of the articles. But there are also plenty which need lots of
> work, and I enjoy wrestling with these ungainly creatures, restructuring
> them, chopping out redundancies, tightening up the prose, adding
> sub-headings and good intros, improving transitions, etc. etc. etc.
>
> Of late, however, I have been coming into conflict with another user,
> whom I will refer to as X.


subject: [Wikipedia-l] Re: [Wikitech-l] Re: The New French Editor and edit war

body:
--- Fred Bauder <fredbaud at ctelco.net> wrote:
> Yes, one of my grave defects is love of stirring up
> trouble.
>
> Vincint,
>
> I hope you can see, apart from the fun we are
> having, that anyone who logs
> on to the French Wikipedia, not just Anthere, can
> edit your article. I
> sympathise with your view that you should be able to
> maintain the integrity
> of your article and in most publishing situations
> you could, (like fun) but
> where you are you can't due to the GNU copyright
> (which by publishing on
> Wikipedia you have implicitly agreed to). I hope
> this clarifies the
> situation.
>
> Fred Bauder

Since it could be going into legal matters, I switch
to the main list. Ultimately, this could concerns
Jimbo.

I should add that we are slowly proceeding toward an
agreement on the [[religion grecque]] page.

That is, I am boldly going toward each step upon which
we can find an agreement, and let issues such as his
use (and my breaking) of non-breakable caracters, use
of fancy div, use of multiple external anchors between
his articles for later discussion. As I told him,
discussion over anchors are likely to take some time,
it would be sad not to settle an agreement on the
articles themselves. Any relevant links against
technical or practical use of external anchors will be
welcome, advice from french speaking as well, as
Vincent is claiming this opinion of mine is only mine.
Partially true, as there is no rules against using
anchors. Except for Vincent as external anchors, I
believe most anchors have been used in "list of xxx"
as internal anchors, which I can live with. My issue
is mostly a question of easiness of editing, and
mostly linking. I think we have to take time for
issue, and  proceed slowly.

just to make you laugh, I must also say he is
currently considering I was acting against the rules
of Wikipedia, when I refused to protect the page, as
he requested it. He claims edit wars rules that
protection is mandatory, and that his wishes for
protection are not respected, and that I am forcing my
personal belief in what Wikipedia should be (but is
not) by refusing to protect it myself !

My, this is fun ! I would never have believed someone
in a war "against" me would so deeply reproach "me" to
refuse to "protect" the page against "his" edits!

172 ! come over here :-) (just kidding, right ?)

------------

However, I would like to insist on the *legal matter*,
as I think, should Vincent proceeds along the lines he
has been suggesting, this will be a problem for Jimbo.

Here
http://fr.wikipedia.org/wiki/Discussion_Utilisateur%3AVincent_Ramos

Vincent explains that

* he can prove he is the main author of some articles
(he gives this link as an example
http://fr.wikipedia.org/w/wiki.phtml?title=Sanskrit&action=history

* he can show further proofs of him being the author,
such as school notes (I suppose he teaches that
topic), or articles notes

* he knows where to seek legal advice. He adds that he
does not want to do that, but should he has further
problem with his intellectual ownership to these
articles I insist on editing, he will know where to go

* He further add that there is no legal notion of
copyright in France anyway

* that he is a scholar, who accepted nicely to spent
his time here, and to give us his work free of right
because he liked Wikipedia concept. However, he says
he can't tolerate my attitude that consist in
incoherently editing his perfectly good articles, to
modify along my own views, when not everyone share
them (note : absolutely no one gave any comment on the
article content itself and my proposition of division,
that he incidentely accepted)

* that if I further proceed in editing his articles,
he would remove everything he wrote and would have his
(oops I dunno how to say that) legal rights respected,
in a way to quit wikipedia and let it in the same
state that it was before he gots there. He add he
would be very sad if that should happen.

(note : his articles are very interesting, though they
are not always very accessible to everyone imho. Some
have been a little bit rework by others (mostly
wikification, I tried a couple of time to do more, and
was ill-received, which is why I suspected a strong
owernership problem)

* he also says he will not tolerate that one (note :
me) decide I have any rights in a system with no
hierarchy : and that if I refuse to respect structures
in place to facilitate edit war, it is my choice, but
that I do let him any possibility than to (what he
wrote in the edit war article, which is basically that
I am a vandale). (note : what he is hinting at here,
is my refusal to protect the page I am on war on, and
my proposition to discuss the matter instead, rather
than letting other more knowledgeable people decide
what is best).

Well...

I must add that a couple of people expressed I was
right on the copyright point (I tried to explain to
him what the license implied, and that he implicitely
agreed to proceed under this license each time he
pushed on "save"), but it does not appear clear he
understands the point.

All in all, he is a very good contributor, but a
disaster as a collaborator. As long as no one touches
his articles, all is fine (and little do so, as these
are expert and very well research topics), if someone
remove a single sentence from anything he wrote, he
says it is abusive.

Anyway, I am used to being the bugging one :-)

I don't think this will proceed any further in the
next weeks. But, I wanted to make clear what the
problem is, for any further edit wars (which will
undoubtely occur again). I learn the hard way from my
peers I can't own articles, I can teach others as well
perhaps.

Yours

Anthere

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Vicki Rosenzweig

subject: [Wikipedia-l] Fwd: Wikipedia e-mail

body:
I got this email this morning. I'm not sure what the sender means
by my "advertising [my] business as well"--possibly the note on my
user page that I'm available for freelance editing. Mostly, I'm not sure
who she (or he) is, or what prompted this, so I'm passing it along
in case it makes sense to anyone else.

Vicki

>X-From_: apache at larousse.wikipedia.org  Fri Jul 25 20:39:52 2003
>X-Original-To: vr at panix.com
>Date: Sat, 26 Jul 2003 00:39:48 GMT
>To: Vicki Rosenzweig <vr at redbird.org>
>Subject: Wikipedia e-mail
>From: Mallarray <mallarray at aol.com>
>Reply-To: Mallarray <mallarray at aol.com>
>To: Vicki Rosenzweig <vr at redbird.org>
>X-Mailer: Pediawiki interuser e-mailer
>X-Spam-Status: No, hits=0.0 required=5.0
>         tests=none
>         version=2.54
>X-Spam-Level:
>X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
>
>Re my book plug as you call it - you seem to be advertising your business
>as well.  Fair enough as it's Wikipedia I will amend it.

--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


body:
Timwi wrote:

> tarquin wrote:
>
>> * links:
>> everyone here seems to hate underlined links.
>
>
> Nooo! Whatever you do, don't remove the underline!! ;-)
>
> And most of all, the underline shows whether two words are separate
> links or not. Since I hardly ever use the mouse, the hover effect
> wouldn't help me. Pretend I had some sort of disability that prevents
> me from using the mouse at all, and then think in terms of
> accessibility :)

Underlines links are already out in standard skin.
People complain that with heavy linking, a page has too many underlines
-- but we're a HYPERTEXT! links are what we do!

I think there's a case to be made for having underlined links in the
*default* skin at least. I'd like to put them in hover at least.
(have you set your browser stylesheet to force them, BTW?)

> You don't need to know any PHP for this. If you just search all the
> files for 'ffffff', you find Skin.php, Line 124. I'll quote Lines
> 121-124:
>
>         if ( 0 != $wgTitle->getNamespace() ) {
>             $a = array( "bgcolor" => "#FFFFDD" );
>         }
>         else $a = array( "bgcolor" => "#FFFFFF" );
>
> Clearly, these are the background colours for meta-namespaces and the
> article namespace. Seeing as 'ondblclick' and 'onload' are also used
> in the same routine, you can probably safely change this to
>
>         if ( 0 != $wgTitle->getNamespace() ) {
>             $a = array( "class" => "meta" );
>         }
>         else $a = array( "class" => "encyclopedia" );
>
>
thanks!


from_name: limholt at excite.com

subject: [Textbook-l] Proposals in Wikitext

body:
I've been offline for a couple of days, and suffering from Wiki-withdrawal symptoms. ;(.
But, while I still have Wikipedia work to finish before making many contributions on Wikitext, I used the time to organize some thoughts.

I call your attention to one of these, related to hierarchy of texts and textbook general thoughts. You can comment on or see the first at <http://textbook.wikipedia.org/wiki/Textbook_libraries> and the second at  <http://textbook.wikipedia.org/wiki/Textbook_planning>.

I'll post the second page pointed to on planning as soon as I finish reviewing contents of the mail list for related material. But, I would suggest that we soon move the discussion of development process questions to the Wiki itself rather than the mail list, then reserve the mail list to call attention to major changes or extended discussion.

Now, back to the Wiki :)

Regards, Lou Imholt (LouI on Wiki)

_______________________________________________
Eliminate pop-ups before they appear!
Visit www.PopSwatter.com now - It's FREE.


subject: [Wikitech-l] Re: Phase IV

body:
Erik Moeller wrote:

>for En:) has been very high, and our page parser is very ugly and slow.
>Clearly we need optimizations on both fronts.
>
>Please do take a look at the Wookee parser module that Tarquin pointed to.
>It uses a syntax very similar to Wikipedia's.
>http://wiki.beyondunreal.com/wiki/Wookee
>
>
>
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.


from_name: Jimmy O'Regan

subject: [Wikipedia-l] PNG format???

body:
Ralphem at aol.com wrote:

>JPEG AND GIF are the standards for use on
>the web
>
 From [[PNG]]:

    Version 1.0 of the PNG specification was released on 1 July
<http://www.wikipedia.org/wiki/July_1> 1996
<http://www.wikipedia.org/wiki/1996>, and later appeared as RFC 2083
<http://www.wikipedia.org/wiki/RFC_2083>. It became a W3C
<http://www.wikipedia.org/wiki/World_Wide_Web_Consortium>
Recommendation on 1 October <http://www.wikipedia.org/wiki/October_1>
1996 <http://www.wikipedia.org/wiki/1996>.

Having an RFC makes it an Internet standard, being recommended by the
W3C makes it a web standard. Simple solution: update your browser.


from_name: Walter Vermeir

subject: [Wikitech-l] Re: request Admin status

body:
Daniel Mayer <maveric149 at yahoo.com> wrote
in news:200307260301.47035.maveric149 at yahoo.com:

> It would be nice to be able to move pages - so to any developer out
> there; Can I be an Admin for the textbook project?
>
> How active does a wiki have to be to make 'move this page' a non-Admin
> option? Just wondering - no real biggie.
>
> -- Daniel Mayer (user:maveric149 internal ID #7)

I am not a sysop on Wikipedia EN but i can move a page there. So far I know
the "move this pages" is an option for all registerd users on all
Wikipedia. Not only for sysop's

-- Walter Vermeir (gebruiker:walter intern ID #4)


from_name: steve vertigo

subject: [Wikitech-l] Re: Phase IV

body:
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


from_name: James D. Forrester

subject: [Wikitech-l] Re: Phase IV

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26 July 2003 01:15, Timwi <timwi at gmx.net> wrote:

> http://www.lionking.org/~timwi/t/wikipedia/wikipedia-iv.html

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 at eh.org> | <mailto:csvla at dcs.warwick.ac.uk>
<mailto:jamesdforrester at hotmail.com> | <mailto:james at jdforrester.org>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPyJNXZJ95FMWcicdEQIdrgCeOOkmVQyxwDiwAXxpf5C2+CwB/PcAnRoc
ooelB07bpmW1AlfuEoZm0GrH
=QrJN
-----END PGP SIGNATURE-----


from_name: Sheng Jiong

subject: [Wikitech-l] New LanguageZh.php completed

body:
The new locale for Chinese Wikipedia has completed, and can be found at
http://meta.wikipedia.org/wiki/LanguageZh.php
Please install the new locale in the server.

It is now fully localised(in simplified Chinese), but namespaces are
still in English, for the convenience of traditional Chinese users.

I am not sure if it is possible to have two locales for Chinese
Wikipedia, one in traditional Chinese and the other in simplified
Chinese, so that users can choose in their preferences which interface
they want to use.(Currently there is discussion about having both
traditional and simplified characters together in the interface, but I
think that would be very ugly)

It has not been tested, and may have errors.

[[User:Formulax]]


subject: [Wikitech-l] Re: reverse langalinks

body:
Some quick pseudocode (warning - from a non-coder) on
the idea of adding a reverse tag. The main problems
are finding the new tag, and any potential edit
conflict. (minor)

{
langatag="[[(langa):*.*]]
reversetag=[[(thislanguageprefix):article name]]

upon save page
//newlangatag?
compare currentarticle() (limit top paragraph) with
previousarticle() (lim prgh1)
currentarticle tagcount=()
previousarticle tagcount=()
//if same
	save page and terminate.
//if different
     if less than previous
	save page and terminate.
     if more than previous
	findnewtag()

//compare article tags
for tags in currentarticle make an array()
for tags in previous article make an array()

//compare tags in array
for duplicate tags the in both articles, remove from
array

//for each remaining tag()

access target article
cue top of the page
add reversetag()  //
[[currentlanguage:currentarticle]]
save article

//if article is changed by a bot during a useredit,
add a bot message.

}
.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


body:
The Day of Slack was supposed to last all year, but oh
well...

It would be a mistake to not take action and always
defer to the management on each special case -- truth
is most cases are what they are.  Theres a reason why
referees let hockey players spill some blood on the
floor when a fight breaks out - and perhaps this
should be the temperment of anyone trying to break up
an edit war... (which I think are healthy, if they are
limited in time)  It will never be as simple as
pressing a button to stop a heated discussion.

172 broke protocol -- Erik aint perfect -- whats the
big frickin stink about?

-S-

Axel-
> I am thankful for your handling sysop requests on
Wikipedia.
This does
> not include your unsysoping people with whom you had
a
conflict,
> without prior discussion on this list.

It is hardly accurate to describe my actions as
"unsysoping
people with
whom I had a conflict." As a matter of fact, I made
explicitly
clear in my
mail that I agreed with 172's assessment of the
changes to
[[Catholicism]]. What I did is try to enforce our
existing
Protected Page
policy. I will not do this in the future unless there
is a real
emergency
(a sysop protecting hundreds of pages without need
etc.).
Instead, I will
send a mail to Jimbo and he will then inform the list
if he
thinks a
decision is necessary.

Regards,

Erik

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


body:
Anthere-

> ----- his comment

> Dernier avertissement. Ensuite, je serais d?sol? de le
> faire, mais apposerai mon copyright sur cette page
> (les documents m'attribuant la paternit? de son
> contenu ?tant ? c?t? de moi).

> ----which means

> Last warning. Next time, I will be sorry to do it, but
> I will add my copyright on this page (the documents I
> have just next to me attribute me the paternity of its
> content)

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


subject: [Textbook-l] request Admin status

body:
Daniel-
> It would be nice to be able to move pages - so to any developer out there;
> Can I be an Admin for the textbook project?

You don't need to be admin to move pages, you just need to be logged in.
Do you still want to be admin?

Regards,

Erik


subject: [Wikitech-l] Re: [Textbook-l] request Admin status


from_name: Lightning

subject: [Wikitech-l] Re: Phase IV

body:
Hunter Peress wrote:

>>Timwi-
>>
>>
>>>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.
>>>
>>>
>
>Python has a profiling module. See an example which i used to find bottlenecks in the
>bittorrent code: http://24.175.39.66/~hperes/btdh_upload_only_XP1800_20minutes_runtime.txt
>
>
>
>
>>Well, that's not necessarily true. CPU usage on Larousse (the webserver
>>for En:) has been very high, and our page parser is very ugly and slow.
>>Clearly we need optimizations on both fronts.
>>
>>
>
>Python has an amazing JIT/code optimizer named psyco (psyco.sf.net). Most
>text processing type operations are sped up to the level of pure C. I
>wrote a difflib module (almost identitical to our difflib.php here) in C/python
>api and psyco (when run on the pure python version) met it's performance.
>
>
>
>
>>>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.
>>>
>>>
>>>
>>Well, then test it. Throw some 10 megabyte files into the database and
>>compare the reading performance with multiple threads to direct Apache
>>server access.
>>
>>
>
>YES. test,test,test. This is the precept of extreme (and proper) programming.
>
>
>
>>Perl-OOP is a bit ugly, but reasonably powerful. Check out perldoc
>>perltoot for details. You'll want to look at "tie" especially, as this
>>allows you to do some cool stuff with properties.
>>
>>
>
>Mainly its just ugly. Perl is a horrible language whose time has passed. Its number
>one bad feature is confusion. Perl allows more unmaintainable and entropic code
>than most any language except brainfuck. It's development is pathetic over the last few
>years, the language and community have no focus.
>
>Python is a language that is only 1 year younger than perl (1990). Its had threads since
>the beginning, whereas perl just obtained them last year for example... Python has no bad
>features, in that it only allows for low entropy code. It has a rich standard library, and is
>accepted widely.
>Read this oreilley publication http://www.onlamp.com/pub/wlg/3198 which covers 8 stories in big
>industry (industrial-light-and-magic ILM for example) and how after years of working with things
>python is the number 1 language of choice over php, perl, c, java, lisp.
>
>There is a great wiki written in python, called moin moin, its filed based even, not database
>based, and i believe that this avenue is more lightweight and deserves some consideration.
>Yes...ive followed all wikipedia's static-file "to cache or not to cache arguments...".
>
>There are great idioms and frameworks out there to make content management and web publishing
>low-entropy and maximally effective.
>
>Namely: zope's cmf: http://cmf.zope.org/
>AND  twisted.woven: http://twistedmatrix.com/documents/howto/woven
>and of course...mod_python which is in-apache.
>
>Heck...this wikitech mailing list (list.org)  is written in python.
>
>google, yahoo , various goverments accross the world all prefer python. Dynamically typed
>langauages
>like perl, python, and php are far more productive than anally typed java/ocaml. And archaic
>langauges like c++, c, fortan.
>
>
I'm sorry but asm uch as I dislike perl, I would never advise replacing
it with a language that has interpreted whitespace. thats just asking
for a bunch of stupid little errors. Uninterpreted white space IMHO is
the greatest feature of programming languages in genereal, I love those
magic curly braces....  I don't have anything against python, just that
single particular aspect.

Lightning


subject: [Wikitech-l] Re: Phase IV

body:
James D. Forrester wrote:

> 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.

Its been discussed.. the answer is unfortunately no because of many
reasons. including the factt hat there is not allways a 1:1 relation
ship between articles. I will not go into this further because its been
discussed a zillion times, check the archives if you want more info.

>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...
>
I am from the school where they teach you that if you have DB problems,
you don't go using it as a filesystem... The way I would do it is upload
every image with an image-id and a rev- id like 3-1.png or 99-123.jpg.
The database table for images contains the id's with, length, filesize,
and format.  You just place a normal http request for the image. BUT
here's the thing instead of just running apache, we run a apache for the
php pages and some super-lightweigh server that just serves out the
images. it can be on the same or another server.. call it
images.en.wikipedia.org.. or imagenes.es.wikipedia.org.   Get y point?
that way we take some load from apache, who is much less efficient at
just serving out these single files because its so much larger, it has a
bunch of modules compiled into it and has to check things like rewrite
rules etc.. This is just a simple easy way to save some memory, and
since files are identified by a conbination of id and revision id, thre
is never any worry of accidentally overwritting something.

Thoughts or concerns?   Yes I know it doesnt scale THAT well.. but at
the time we have 2 servers for something like 20 wikis. And unless money
starts falling magically out of the sky it might stay that way for a
while. I just don't see load balancers and clustering in the near
feature.. unless once the wikimedia foundations someone donates a whole
lot of money into it...

Lightning


subject: [Wikitech-l] Re: Phase IV

body:
tarquin wrote:

>
>
> Lightning wrote:
>
>> I love those magic curly braces....
>
>
> I love the way that in perl, you can put curlies *anywhere*, and
> declare local vars to that curly block  :)

yeah i love that too.. thats pretty slick. I allways like using
namespaces and lots of curlies in c++ my teacher hated me because of
that and my constant habit of running a search and replace on my code
before i turned it in for grading.. I used to search and replace all
variable names and rename then with names like  "sdfd", "frtb",
""w4gyr"  .. lol    oh. he never thought it was that funny, especially
afeter i stripped all the comments and indention..... i thought it was
funny

Lightning


subject: [Wikitech-l] RE: Phase IV

body:
all responses so far are pure reactions, and show that no one acknowledged much of what i brought
forth:

That python has an optimizing JIT (that we used on f.scarywater.net which is a BitTorrent server
that handles 12,000 users, and saw a 40% decrease in CPU load). That i have personally written
things in C and that this JIT has met its performance. That it has a profiler.

That it is a language with focus  http://www.python.org/dev/culture.html and professional
acceptance specifically over all languages (see the oreilly link).

Whitespace as a cause of errors? jeez... ever heard of unit testing ?

Simply moronic.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com