subject: [Wikipedia-l] ISBN links

in_reply_to: <87zo93avwu.fsf@orcus.priv.at>; from robbe@orcus.priv.at on Tue, Aug 14, 2001 at 10:27:29AM +0200

body:
I'm loosely inclined to agree with you.  The Amazon link is part of the
default setup in the code from Clifford Adams.  We should surely at least
change it to be a revenue-earning code, after all if we are going to
send business in the direction of a company we aren't entirely comfortable
with ethically, we should at *least* make them pay for it.  :-)

And yes, of course we would earmark the money for wikipedia.

Robert Bihlmeyer wrote:

> The automatic links to booksellers provided with ISBN numbers are a
> good feature overall.
>
> I'd rather have them not point at Amazon, though, since they are
> obviously against freedom (keyword: 1-click patent), and didn't
> respect my privacy (details on request). I would be more comfortable
> with links to other outfits (Barns & Noble, whatever).
>
> Obviously you may differ on this issue, and if the links to Amazon are
> kept, I suggest that they use the Amazon Honor System. With this Bomis
> would receive payment for every traffic that reaches Amazon through
> one of those links (just like with banner ads). AFAIK, the only thing
> that must be changed is the base URL used in those links (e.g. putting
> /wikipedia/ somewhere in there), and of course registering with
> Amazon. If you implement this, please put up some page stating where
> the money goes. I'd expect Bomis to earmark the money for the hosting
> & maintaining costs of wikipedia, but it's always good to have an
> explicit statement.
>
> Perhaps other booksellers offer similar deals, or they could be worked
> out individually.
>
> What do others think?
>
> --
> Robbe

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


list: wikipedia-l

source: pipermail-mbox

from_name: Jimmy Wales

subject: [Wikipedia-l] Making Wikipedia more Google friendly

in_reply_to: <200108141259.OAA09149@atm2.uni-paderborn.de>; from axel@uni-paderborn.de on Tue, Aug 14, 2001 at 02:59:17PM +0200

body:
Yes, this change should be made immediately.  If it doesn't happen
within 48 hours, please remind me.

Axel Boldt wrote:

> When you do a search on Wikipedia or click on a link, the returned
> URL looks like http://www.wikipedia.com/wiki.cgi?Poker
> If somebody likes this page and links to it, then in principle that
> should increase our standing with Google. But Google doesn't like CGI
> links. It would be better if the wiki script always returned links of
> the form http://www.wikipedia.com/wiki/Poker (actually, I would have
> prefered http://www.wikipedia.com/Poker, but that's too late now).
>
> Is the source code of our wiki perl script available somewhere?
>
> Axel
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] Wikipedia teamwork

body:
Bryce Harrington wrote:
> Anyway, I'm a little miffed - you said your programmers were too busy,
> and that you'd appreciate it if someone would supply code to do it.  I
> responded with some code that would do the minimum needed to comply
> (just change the paths).  I was anticipating a thank you, but instead
> "It does no good to post it here"?  Well, call me confused.  ;-)

I understand and appreciate your confusion.  I was on vacation last
week, and Larry doesn't really have the means to make things happen
that I do.  He also doesn't know much about technical matters, so
he probably didn't realize that you had already supplied code, etc.,
etc.

I'm back now, and we'll have this resolved pronto.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


from_name: Larry Olin Horn

subject: [Wikipedia-l] Re: ISBN links

body:
[I've had this in my pending folder since the 16th.  Forgot about it until I saw JW's post, so it doesn't sound like a direct reply.]

This is trivial compared to most of the requested features, but
I'm submitting it as a trial baloon, so to speak,
the idea being that some sample code might be more encouraging
that just saying "I want this feature" w/o giving any thought
to how it might work.

Really, I just want to know if submissions like this are acceptible,
or if you'd rather not bother with them.

One request was that the ISBN links be more explicit, so here's
the skeleton of a solution.

First, the ISBNLink function in wiki.cgi is simplifed (first
enclosure below); it just creates a link to an external script
that looks like

    ISBN nnnnnnnnn

The external isbn.cgi script (DEMO below) produces a page that
looks like:

     (standard header here)

     global explanation blah blah blah ....

     Barnes and Noble - blah blah blah ...

     Amazon - blah blah blah ...

     Pricescan - blah blah blah ...

    (standard footer here)

where the company names are the links to their respective ISBN
lookups and the "blah blah blah" is whatever fixed disclaimer/writeup
that Wikipedia/Bomis wants to use.

Being the lazy guy that I am, the proper coding of isbn.cgi for
security and your local standards is left for someone else (grin).

loh

[this is UseMod 0.92; I've not downloaded the Wikipedia tarball]
---------- replacement for ISBNLink() ----------
sub ISBNLink {
  my ($rawnum) = @_;
  my ($rawprint, $html, $num, $first, $second, $third);

  $num = $rawnum;
  $rawprint = $rawnum;
  $rawprint =~ s/ +$//;
  $num =~ s/[- ]//g;
  if (length($num) != 10) {
    return "ISBN $rawnum";
  }

# LOH: begin modification
# replace direct ISBN links with external script
#
#  $first  = "";
#  $second = "" . T('Amazon') . "";
#  $third  = "" . T('PriceScan') . "";
#  $html  = $first . "ISBN " . $rawprint . " ";
#  $html .= "($second, $third)";
#
   $html = "ISBN $rawprint";
#
# LOH: end modification

  $html .= " "  if ($rawnum =~ / $/);  # Add space if old ISBN had space.
  return $html;
}
---------- cut here ----------

---------- isbn.cgi ----------
#! perl

##### WARNING: CONCEPT DEMO ONLY - THIS IS NOT GOOD CODE!  #####

$query = $ENV{'QUERY_STRING'};

print "Content-type: text/html\n\n";

print "";
print "<title>Look up ISBN $query</title>";
print "\n";

print "
standard header here
\n";

print "global explanation blah blah blah ....
\n";

print "
";
print "Barnes and Noble - ";
print "blah blah blah ...";
print "</lp>\n";

print "
";
print "Amazon - ";
print "blah blah blah ...";
print "
\n";

print "
";
print "Pricescan - ";
print "blah blah blah ...";
print "
";

print "
standard footer here
\n";

print "";
print "\n";

__END__

# end
---------- cut here ----------


from_name: kpjas at promail.pl

subject: [Wikipedia-l] Just wiki.cgi script - please

body:
Hello all,

Could someone please send me or put up on a page somewhere just the
wiki.cgi script from the English tarball distro ?
I'd be very much grateful.

Regards,
kpj.
--
Krzysztof P. Jasiutowicz, M.D | Zawsze jestem got?w si? uczy?, chocia? nie
Czestochowa, Poland ...       | zawsze chc?, ?eby mnie uczono. Winston S.
Wi?cej cytat?w : http://www.cytatowo.prv.pl


from_name: Gareth Owen

subject: [Wikipedia-l] Question regarding existing links

in_reply_to: Peter Jones's message of "Wed, 22 Aug 2001 20:45:25 +1000"

body:
Peter Jones <jonespr at optushome.com.au> writes:

> I don't want to re-save the page just to fix the link.  Is that what I
> have to do?

Yes.  I think its a result of how the wiki software caches pages.  Add some
whitespace, click "minor edit" and resave...

> (Or is there a script which runs through the wikipedia on a regular basis
> and fixes all these dangling edit links that are no longer dangling?)

I don't know, but its a good idea

--
Gareth Owen


from_name: Larry Sanger

subject: [Wikipedia-l] Re: ISBN links

body:
This is a great idea...what we've got to figure out (and we are now figuring
it out) is how to let folks collaborate on Wikipedia's software.  Probably,
a CVS system is in order.  We'll definitely keep you updated, but we've got
to talk things over with Clifford first.

Larry

----- Original Message -----
From: "Larry Olin Horn" <hornlo at lohnet.org>
To: <wikipedia-l at nupedia.com>
Sent: Tuesday, August 21, 2001 8:37 PM
Subject: [Wikipedia-l] Re: ISBN links

> [I've had this in my pending folder since the 16th.  Forgot about it until
I saw JW's post, so it doesn't sound like a direct reply.]
>
>
> This is trivial compared to most of the requested features, but
> I'm submitting it as a trial baloon, so to speak,
> the idea being that some sample code might be more encouraging
> that just saying "I want this feature" w/o giving any thought
> to how it might work.
>
> Really, I just want to know if submissions like this are acceptible,
> or if you'd rather not bother with them.
>
>
> One request was that the ISBN links be more explicit, so here's
> the skeleton of a solution.
>
> First, the ISBNLink function in wiki.cgi is simplifed (first
> enclosure below); it just creates a link to an external script
> that looks like
>
>     ISBN nnnnnnnnn
>
>
> The external isbn.cgi script (DEMO below) produces a page that
> looks like:
>
>      (standard header here)
>
>      global explanation blah blah blah ....
>
>      Barnes and Noble - blah blah blah ...
>
>      Amazon - blah blah blah ...
>
>      Pricescan - blah blah blah ...
>
>     (standard footer here)
>
> where the company names are the links to their respective ISBN
> lookups and the "blah blah blah" is whatever fixed disclaimer/writeup
> that Wikipedia/Bomis wants to use.
>
> Being the lazy guy that I am, the proper coding of isbn.cgi for
> security and your local standards is left for someone else (grin).
>
> loh
>
> [this is UseMod 0.92; I've not downloaded the Wikipedia tarball]
> ---------- replacement for ISBNLink() ----------
> sub ISBNLink {
>   my ($rawnum) = @_;
>   my ($rawprint, $html, $num, $first, $second, $third);
>
>   $num = $rawnum;
>   $rawprint = $rawnum;
>   $rawprint =~ s/ +$//;
>   $num =~ s/[- ]//g;
>   if (length($num) != 10) {
>     return "ISBN $rawnum";
>   }
>
> # LOH: begin modification
> # replace direct ISBN links with external script
> #
> #  $first  = " #            . "isbnInquiry.asp?isbn=$num\">";
> #  $second = " #            . "ISBN=$num\">" . T('Amazon') . "";
> #  $third  = " #            . "BookDetail.asp?isbn=$num\">" . T('PriceScan') . "";
> #  $html  = $first . "ISBN " . $rawprint . " ";
> #  $html .= "($second, $third)";
> #
>    $html = "ISBN $rawprint";
> #
> # LOH: end modification
>
>   $html .= " "  if ($rawnum =~ / $/);  # Add space if old ISBN had space.
>   return $html;
> }
> ---------- cut here ----------
>
> ---------- isbn.cgi ----------
> #! perl
>
> ##### WARNING: CONCEPT DEMO ONLY - THIS IS NOT GOOD CODE!  #####
>
> $query = $ENV{'QUERY_STRING'};
>
> print "Content-type: text/html\n\n";
>
> print "";
> print "<title>Look up ISBN $query</title>";
> print "\n";
>
> print "
standard header here
\n";
>
> print "global explanation blah blah blah ....
\n";
>
> print "
";
> print "Barnes and Noble - ";
> print "blah blah blah ...";
> print "</lp>\n";
>
> print "
";
> print "Amazon - ";
> print "blah blah blah ...";
> print "
\n";
>
> print "
";
> print "Pricescan
 - ";
> print "blah blah blah ...";
> print "
";
>
> print "
standard footer here
\n";
>
> print "";
> print "\n";
>
> __END__
>
> # end
> ---------- cut here ----------
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Peter Jones

body:
Just a quick question regarding links.

I have just revised an entry (Blade Runner) which included a link to
"Philip K. Dick/Do Androids Dream of Electric Sheep".  I then went and
created a page for "Do Androids Dream...".  When I go back and look at
the Blade Runner page again, the link in question still appears as an
edit link, rather than a "normal" link.  However, if I re-edit the Blade
Runner page and hit [Preview], the preview displays correctly.

I don't want to re-save the page just to fix the link.  Is that what I
have to do?  Or am I doing something else wrong?  (Or is there a script
which runs through the wikipedia on a regular basis and fixes all these
dangling edit links that are no longer dangling?)

Pete.


subject: [Wikipedia-l] Re: ISBN links

body:
> This is a great idea...what we've got to figure out (and we are now figuring
> > [I've had this in my pending folder since the 16th.  Forgot about it until

Duh.  I really should get more sleep.  Although I'd not sent the message, I
had instead posted it on Wikipedia.  Sigh.

sorry,
loh


from_name: Tim Chambers

subject: [Wikipedia-l] nifty form to search Wikipedia via Google

body: Have a look at http://timothy.swiki.net/39. It's on my Todo list.


from_name: Robert Bihlmeyer

subject: [Wikipedia-l] Talk policy

body:
Hi,

I often stumble over /Talk pages containing requests for changes,
clarification, or similar, which are outdated by the main page's
progress. An example of many is
<URL:http://www.wikipedia.com/wiki.cgi?action=browse&id=LISP_programming_language/Talk&revision=1>:

> Page for discussion ...

Fluff, removed now.

> "... and is therefore the oldest programming language ..."

with arguments why this is false. Notion has been corrected in the
article. Following is a section acknowledging the error.

> "... and CDR (Contents of Address Register) ..."

Pointing out a typo, which has been fixed. Another section
acknowledging this error follows.

> Function CAR in LISP program returns ...

I don't know what this is, perhaps a suggested addition to the article?

So, one section is still relevant, the other four or five were used by
people to showcase problems that they were not sure enough about to go
ahead and correct them. I'm unsure what should be done about these
no-longer-relevant bits.

My preferred alternative is deleting them outright, and make the
following guideline: If you implement a suggestion from a /Talk page,
be sure to delete the suggestion as well. It is no longer relevant to
the current revision of the article.

The counter argument that holds me back is that the discussion
provides background reasoning to changes, especially regarding more
contentious topics.

(Obviously this does not apply to the CAR/CDR change, so I decided to
remove that as well, now.)

Thoughts?

--
Robbe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20010823/a6e4e532/attachment.pgp


subject: [Wikipedia-l] Talk policy

in_reply_to: <87elq33z8j.fsf@orcus.priv.at>; from robbe@orcus.priv.at on Thu, Aug 23, 2001 at 11:24:44AM +0200

body:
I think you are absolutely correct in all aspects of your reasoning.
In many cases, the /Talk pages should be refactored when the main page
has been changed to the satisfaction of all the talkers.  In some
cases, this will not be true.

In some cases, deletions to the /Talk page should wait several days
until all the contentious parties have had a good chance to mull it
over.  For example, there might be a 3-way debate.  A and B are initially
in agreement, and C dissents.  B is convinced by C's dissent and changes
the main page, noting on the /Talk page the reasons.  It would be nice if
A had a few days to decide whether to press the issue further, and simply
deleting the talk page on the assumption that B's conversion is tantamount
to consensus might be unwise.

One useful "middle of the road" solution is to *refactor* rather than *delete*
the /Talk.  That is, to rewrite the talk page to sum up the debate that was
held, giving the rationale for the existing version of the page.  This leaves
things a bit more open to further debate, while at the same time "cleaning house"
in a useful way.

I think that when we come across an old talk page that seems to be about an
uncontroversially corrected error, we should feel free to just delete the whole
discussion.

All in all, I think that no *simple* policy can be stated.  As long as we have
a friendly and helpful community striving for consensus, then individual judgment
will serve to guide us quite nicely.

Robert Bihlmeyer wrote:

> Hi,
>
> I often stumble over /Talk pages containing requests for changes,
> clarification, or similar, which are outdated by the main page's
> progress. An example of many is
> <URL:http://www.wikipedia.com/wiki.cgi?action=browse&id=LISP_programming_language/Talk&revision=1>:
>
> > Page for discussion ...
>
> Fluff, removed now.
>
> > "... and is therefore the oldest programming language ..."
>
> with arguments why this is false. Notion has been corrected in the
> article. Following is a section acknowledging the error.
>
> > "... and CDR (Contents of Address Register) ..."
>
> Pointing out a typo, which has been fixed. Another section
> acknowledging this error follows.
>
> > Function CAR in LISP program returns ...
>
> I don't know what this is, perhaps a suggested addition to the article?
>
> So, one section is still relevant, the other four or five were used by
> people to showcase problems that they were not sure enough about to go
> ahead and correct them. I'm unsure what should be done about these
> no-longer-relevant bits.
>
> My preferred alternative is deleting them outright, and make the
> following guideline: If you implement a suggestion from a /Talk page,
> be sure to delete the suggestion as well. It is no longer relevant to
> the current revision of the article.
>
> The counter argument that holds me back is that the discussion
> provides background reasoning to changes, especially regarding more
> contentious topics.
>
> (Obviously this does not apply to the CAR/CDR change, so I decided to
> remove that as well, now.)
>
> Thoughts?
>
> --
> Robbe

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


in_reply_to: <001501c12be9$75cf9fc0$80441d82@cos.agilent.com>; from tbc+wikipedia@cos.agilent.com on Thu, Aug 23, 2001 at 09:37:02AM -0600

body:
This is very nice.

Today (IF I GET TIME, ha ha) I am planning to do a major change to the
existing wikipedia search engine.  I think I'll add this method as an
optional approach.

Tim Chambers wrote:

> Have a look at http://timothy.swiki.net/39. It's on my Todo list.
>
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


from_name: Mark Christensen

subject: [Wikipedia-l] Talk policy

body:
I also brought this subject up in the Wikipedia itself.  I think it's
important to refactor discussions.  The key sociological differences between
Usenet and a wiki is that the ability to make instant additions and add to
discussions is balanced by the ability to edit what has come before.  If
Larry's correct in worrying about the Wikipedia becoming just another
discussion group, the way we should go about fixing that is to refactor
discussions.

Anyway, I don't buy the argument that since refactoring a /talk page is a
complex issue there are no rules we can apply.  For example, I think we can
say:

1) It's generally better to refactor /talk pages to summarize the previous
discussion than to delete that discussion.

2) Refactoring should not take place until the discussion has either died
down, or moved on to a new topic.

3) If there's a long discussion between two people, and it's slightly off
topic, feel free to move it to a new page, and replace it with a link to the
new page (a sub page of one of the involved parties is a good idea.)

4) When refactoring a /talk page, look for content which should be added to
the main encyclopedia page.

If we go back to the origonal post, I agree that talk about a simple
typographical error should not exist, and can be deleted imediately.  If you
find a typo, go ahead and fix it, don't just post a gripe.

-----Original Message-----
From: Jimmy Wales [mailto:jwales at bomis.com]
Sent: Thursday, August 23, 2001 1:28 PM
To: wikipedia-l at nupedia.com
Subject: Re: [Wikipedia-l] Talk policy

I think you are absolutely correct in all aspects of your reasoning.
In many cases, the /Talk pages should be refactored when the main page
has been changed to the satisfaction of all the talkers.  In some
cases, this will not be true.

In some cases, deletions to the /Talk page should wait several days
until all the contentious parties have had a good chance to mull it
over.  For example, there might be a 3-way debate.  A and B are initially
in agreement, and C dissents.  B is convinced by C's dissent and changes
the main page, noting on the /Talk page the reasons.  It would be nice if
A had a few days to decide whether to press the issue further, and simply
deleting the talk page on the assumption that B's conversion is tantamount
to consensus might be unwise.

One useful "middle of the road" solution is to *refactor* rather than
*delete*
the /Talk.  That is, to rewrite the talk page to sum up the debate that was
held, giving the rationale for the existing version of the page.  This
leaves
things a bit more open to further debate, while at the same time "cleaning
house"
in a useful way.

I think that when we come across an old talk page that seems to be about an
uncontroversially corrected error, we should feel free to just delete the
whole
discussion.

All in all, I think that no *simple* policy can be stated.  As long as we
have
a friendly and helpful community striving for consensus, then individual
judgment
will serve to guide us quite nicely.

Robert Bihlmeyer wrote:

> Hi,
>
> I often stumble over /Talk pages containing requests for changes,
> clarification, or similar, which are outdated by the main page's
> progress. An example of many is
>
<URL:http://www.wikipedia.com/wiki.cgi?action=browse&id=LISP_programming_lan
guage/Talk&revision=1>:
>
> > Page for discussion ...
>
> Fluff, removed now.
>
> > "... and is therefore the oldest programming language ..."
>
> with arguments why this is false. Notion has been corrected in the
> article. Following is a section acknowledging the error.
>
> > "... and CDR (Contents of Address Register) ..."
>
> Pointing out a typo, which has been fixed. Another section
> acknowledging this error follows.
>
> > Function CAR in LISP program returns ...
>
> I don't know what this is, perhaps a suggested addition to the article?
>
> So, one section is still relevant, the other four or five were used by
> people to showcase problems that they were not sure enough about to go
> ahead and correct them. I'm unsure what should be done about these
> no-longer-relevant bits.
>
> My preferred alternative is deleting them outright, and make the
> following guideline: If you implement a suggestion from a /Talk page,
> be sure to delete the suggestion as well. It is no longer relevant to
> the current revision of the article.
>
> The counter argument that holds me back is that the discussion
> provides background reasoning to changes, especially regarding more
> contentious topics.
>
> (Obviously this does not apply to the CAR/CDR change, so I decided to
> remove that as well, now.)
>
> Thoughts?
>
> --
> Robbe

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************
[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: koyaanisqatsi at nupedia.com

subject: [Wikipedia-l] Talk policy

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20010823/b52da0aa/attachment.diff


subject: [Wikipedia-l] Wikipedia teamwork and 501c3 status

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20010823/5af2eace/attachment.diff


subject: [Wikipedia-l] more Talk policy

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20010823/037b4edf/attachment.diff


subject: [Wikipedia-l] Talk policy

body:
Jimmy Wales <jwales at bomis.com> writes:

> One useful "middle of the road" solution is to *refactor* rather
> than *delete* the /Talk. That is, to rewrite the talk page to sum up
> the debate that was held, giving the rationale for the existing
> version of the page. This leaves things a bit more open to further
> debate, while at the same time "cleaning house" in a useful way.

That sounds like a plan. Did that on the LISP talk page.

I'd still like to keep past discussion from new suggestions. Either by
using new "standard" subpages (e.g. /Reasoning vs. /OpenPoints), or by
sectioning /Talk. The last is probably better until /Talk really
"fills up".

> All in all, I think that no *simple* policy can be stated.

Nevertheless, I've added the following to Wikipedia_policy:

  Whenever you change something on a page because of a request,
  report, or discussion on the associated /Talk page, be sure to
  refactor /Talk accordingly.

--
Robbe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20010823/ea04daf1/attachment.pgp


from_name: Daniel Mayer

subject: [Wikipedia-l] Re:  Re: note to the militia

body:
On Saturday 24 August 2002 12:01 pm, Karen wrote:
> Something I wondered - how do you know who the new users to greet them?
> Do you just look for user names you haven't seen before or is there some
> way to identify them? I'd be happy to do the meet-and-greet but I don't
> know how to do it.

Well - I guess I do it the hard way and scan each edit in all Recent Changes
for a 24 hour period looking for edit link user names (a dead give-a-away)
and for user names I don't remember seeing before. This works for me since I
pretty good reading comprehension and memory.

What would be most useful is a listing of new users that can be accessed from
http://www.wikipedia.org/wiki/Special:Listusers. That way this job would be
much easier.

BTW we really /do not/ have 3498 real users -- a good many of these "users"
logged in only to abuse our upload utility or for other nefarious or
non-contributing reasons (I don't greet any user who hasn't contributed at
all). Is there a way to get rid of many of these no-longer used user accounts
Lee (just the ones that have been inactive for months and whose user pages
are still edit links)?

-- Daniel Mayer (aka mav)


subject: [Wikipedia-l] Re: Meet and greet

body:
On Saturday 24 August 2002 12:01 pm, Ed wrote:
> I'm sure we're all sorry (er, um, glad!) to hear about Mav's new job.

Thanks for the sentiment but I'm still at the same job :-) -- except now I
have 4 days a week of night class in addition to my full time job.

> I've been greeting new users occasionally,
> and as of today I've started
> copying Mav's meet-and-greet template.

Great! Although if you can try to spice the greeting up a bit -- I'm overly
logical and it shows in my greeting.

>I can't promise 3 hours a day of
>anti-vandalism patrol, but I do
>browse Recent Changes frequently.

Yeah, 3 hours is a bit too long -- it would be nice to have a feature whereby
an asterisk (or whatever) is by any edit in recent changes that has not been
viewed by a logged-in user (or better yet a sysop). This would majorly cut
down on duplication of vandalism and copyright infringement patrol effort by
militia members.

Also for me at least it would be a /major/ speed-up improvement to have the
option of having Recent Changes in table format again -- it takes me
/forever/ to scan user names and IPs the way it is now.

> I enjoy encouraging newbies with praise and guidance, and I don't mind
> cleaning up after the uninitiated. But if they refuse to listen, I won't
> hesitate to make 'em stand in the corner (see [[child time-out]]).
>
> Ed Poor

In spite of our differences of opinion in social and political matters I
think you are a great people person and well suited to help with the job or
greeting and guiding.

-- Daniel Mayer (aka mav)


subject: [Wikipedia-l] Searching with Google

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20010824/a21afc0b/attachment.diff


subject: [Wikipedia-l] Multimedia and file uploads

body:
[I'm a bit late in the thread ...]

Stephen Gilbert <sgilbert at nbnet.nb.ca> writes:

> Until then, is there any reason why we couldn't use FTP to upload images?
> An anonymous FTP account allowing us to upload to, say,
> www.wikipedia.com/images would do the trick, and we could simply link the
> pictures from there.

Opening Wikipedia up to unchecked binary upload would also allow a lot
of things in that we'd rather not have. Remember that when ftp was
most popular, /incoming direcories where invariably (ab)used
for illegal exchange of copyrighted material. This has mostly been
mitigated by removing read access to the upload directory to the
public. Probably also by the prolification of gratis web hosters,
where warez can still easily be stored for a few days as well. So I
don't know if this would become a problem.

In true WikiWiki spirit, people should be able to delete/modify
uploaded material as well. This could keep us abreast of the warez
problem, since our editorial staff (aka everybody) could wipe out any
occurance of these. On the other hand, to prevent mischief, we would
probably want to keep past revisions of binaries as well, so that
people could undo changes, or merge them. Unfortunately, here the
warez pop up again.

Binaries, even when they replace a thousand words, usually take more
space than a thousand words. Therefore, resources may also pose a
problem: disk space, access speed, network bandwidth.

While I recognize the fact that images (maybe sounds, much less
animations), genuinely complement some entries (hey, one of the two
pictures in /images/ came from me!), I argue for a very sparing use of
these. The encyclopedias I knew and loved all had only few images. I
know that these are becoming more, and the "multimedia encylopedia" is
the current craze. Call me old-fashioned in that repect, but I think
the advantages of these are by far over-hyped.

As an afterthought, I would want Wikipedia to stay as useful as
possible to people who can't view pretty pictures (because their
hardware won't show them properly, because they lack eye-sight). Add
pictures if you want, but don't replace explanatory text with them.

To wrap up, these concerns make me belief that the current state of
affairs with images trickling in slowly (actually, the installing of
my image was not slow!) is fine. Optimisations of the process, like
setting up a write-only ftp area for people to use instead of mail,
are of course good.

Implementing unchecked binary upload, and keeping it until it becomes
a nuisance, is also an option. You will surely survive any potentially
"I told you so" calls by me. The main loss will be the implementor's
time, then.

--
Robbe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20010824/b996eee9/attachment.pgp


from_name: lsanger at ross.bomis.com

subject: [Wikipedia-l] PHP Wikipedia

body:
On Fri, 24 Aug 2001, Magnus Manske wrote:
> It has all essential wiki features like article editing, version management,
> user management, subpages, etc.

Sounds fantastic.  (Just don't support sub-sub-n-pages, please.)

> Additionally, its data storage is completely MySQL (fast!), it has a file
> upload tool, some other goodies soon.

As far as I'm concerned, the question is: how soon can we test this out?

We don't know when the New York Times article is going to appear, but my
understanding is that it could be as early as next Tuesday.  Probably not
that early, but it's possible.  We might just get a one paragraph mention
and only a little more traffic--but we might be TOTALLY INUNDATED with
traffic.  We've got to be ready.  I'm prepared to work this weekend
helping in whatever way I can, if others are up to it.  (I have to get
vacation days built up for my honeymoon anyway.  :-) )

> Maybe best of all, script and database are prepared to support some kind of
> editor/superuser functionality for "locking" pages, as it is currently
> discussed.

I think that having that functionality isn't a bad idea, but I agree with
Jimbo that we should not lock down pages.  If anyone wants to debate this
precise point again, I'm game.  If you don't understand why we're so
adamantly opposed to it, I think I can make it clearer than I've made it
so far.

No, the best thing of all would be something that can instantly and
*without loss of data or format* transfer Wikipedia pages from UseModWiki
into Wikipedia code.  We could call this Encyclode (encyclopedia + code).
On the other hand, that might be lame.  That's just my idea.  :-)

> Now to the bad sides (yes, there are some...)
> - I don't have a server to host it yet. Maybe I can run it on the Nupedia
> server sometimes. So, no trying yet, sorry.

Jimbo mentioned the possibility of a CVS system--wouldn't take long to set
up.  Unfortunately, it's Friday afternoon...

> - The parser (to convert the source text into readable stuff) is very basic.
> I copied the HomePage and the SandBox from wikipedia, and they look about
> the same, but this is wherte the bugs will be.

Well, you mentioned something about being able to use the UseModWiki
parser.  Could you?  Would that be a way to preserve all the old
UseModWiki formatting?

> Just letting you know there's an early but working alternative ready...

Thanks, Magnus.  I'm eager to see it.

Larry


subject: [Wikipedia-l] PHP Wikipedia

body:
On Fri, 24 Aug 2001, Magnus Manske wrote:
> I guess there are enough people out there who know some PHP, and it's easy
> to learn (easier than CGI, I think). As you know, Nupedia is PHP-based, and
> it works quite well. The script could also become a wikipedia "article"
> itself, which can be copied to a real file after an upgrade or error
> correction. It might be a good idea to limit write access to that "article",
> though. That could make a CVS unnecessary.

But if we had the CVS, we could test the code more easily, couldn't we?
Teach me, o master.

> Which is another thing I need to know. Should I implement a "rights
> management"? If yes, how? Probably group-based, with an "editor" group
> giving out special rights? And limits that can be changes for each page, or
> should that go by page name, like "/Talk is open to everyone, /Lock can only
> be changed by editors"? Please give me input on this!

Basically, if you can swing it, I think each page should have its own
*automatic* talk page that is not counted among the articles.  This has
all sorts of advantages.  Then, eventually, we could automatically port
all the [[Foo/Talk]] contents to the automatic-talk-page contents (if the
latter didn't already have some contents).  (We wouldn't want to do that
by hand.)

> Finally, I'm not sure I can do the long-term of the script maintnance
> myself. I'll work on the rights management and bug-fixing until it runs
> without bugs, of course, and can fix minor things when they pop up. But in a
> few weeks/month, I'll be quite busy at university, and can't promise
> anything there.

I think that's fantastic and no problems.

Larry


in_reply_to: <200108240201.f7O21Qe26873@ross.bomis.com>; from koyaanisqatsi@nupedia.com on Thu, Aug 23, 2001 at 07:01:26PM -0700

body:
I will absolutely be going over all the details with my lawyers before
we finalize anything.  I don't think that the restrictions on
political speech are all that severe for non-profits.  For example,
Consumers Union is always making political statements in their
Consumer Reports magazine, calling for increased regulation of this or
that product category.  And National Geographic magazine has
editorials.

I think you're just barred from campaigning in particular ways for
particular candidates.  It seems unlikely that Wikipedia/Nupedia would
run afoul of that kind of thing.

<political commentary> McCain's "campaign finance reform" bill is a
disaster on this front, as I understand it.  Nonprofit organizations
like Greenpeace or the NRA would be barred from running advertisements
about particular candidates for 90 days before an election.  This
means that voluntary organizations designed to empower individual
political speech would be blocked from their primary mission.
Supporters of those organizations would lose the ability to
effectively make their voice known.</political commentary>

Part of the purpose of doing a nonprofit is to make it "comfortable"
for other people than me to contribute money to the project.  Right
now, I pay all the bills, which is fine for now, but someday this will
grow beyond my capacity (or, my capacity may diminish!), and I
certainly don't expect that anyone will feel comfortable signing on to
donate money to my for-profit company.  :-) Of course, if you feel
like donating money to Bomis, by all means, let me know and I'll make
sure you have the right address.  *wink*

But when Nupedia and Wikipedia are spun off into an entity with a
non-profit charter, I think people will feel comfortable signing up
for "sponsorships", in the same way that people support local theater
groups by becoming patrons.  You could be a "Bronze level" supporter
for $X per month, a "Silver level" sponsor for $Y per month, a "Gold
level" sponsor for $Z per month.  All funds would go toward the improvement
of the project.

That's just an idea, but I know it can't happen as long as I'm personally
funding everything within a for-profit company.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


from_name: Axel Boldt

subject: [Wikipedia-l] Searching with Google

body:
Hi,

I think Tim's Google trick is really cool and until we have a better
search engine ourselves, we should definitely put a search box like
his on our home page.

The only downside is that Google indexes our site only once a month.

On my sites, I have in the past used http://htdig.org. The search
results are just as fast and precise as google's, but you control when
and what you index. A cron script once a night should be fine.

Axel


subject: [Wikipedia-l] PHP Wikipedia

body:
On Fri, 24 Aug 2001, Jimmy Wales wrote:

> lsanger at ross.bomis.com wrote:
> > No, the best thing of all would be something that can instantly and
> > *without loss of data or format* transfer Wikipedia pages from UseModWiki
> > into Wikipedia code.  We could call this Encyclode (encyclopedia + code).
> > On the other hand, that might be lame.  That's just my idea.  :-)
>
> My lame name suggestion is Pediawiki.  "Which wiki software does wikipedia
> run?  Wikipedia runs Pediawiki!  It's the wiki software designed for encyclopedias!"

Huh, I have to admit that my suggestion is lamer than yours.

> > Jimbo mentioned the possibility of a CVS system--wouldn't take long to set
> > up.  Unfortunately, it's Friday afternoon...
>
> Yes, probably Monday morning we can set this up.

Magnus seemed not to like the idea, though.  I'd like to know why,
Magnus...

> There's NO REASON to think that we need to hurry this because of the New York
> Times article.  Our current site will easily survive the load of that, especially
> after I finish speeding up the search engine (later this afternoon, cross your
> fingers).

Well, here's what I'm worried about:

(1) No huge deal, but...it's possible that the RecentChanges page is going
to be, well, even huger than during the recent Slashdotting.  That would
suck, because it would be incredibly unwieldy and messy.  But would that
be a problem, other than that no one could possibly look at even a
significant fraction of all that?  (Which I myself argued isn't that huge
of a problem, in a recent column...)

(2) Edit lock problems might increase if traffic increases radically.
What can we do about this?  It's still a reasonably serious problem right
now--I have removed a half-dozen edit locks today.

(3) The search engine--Jimbo has got that handled, thanks.

(4) Isn't it possible that, with a lot of traffic, the whole website will
just become unusably slow because it's based on text files?  I am asking
out of pure ignorance and blind fear, and need to be educated on this
point.  If we were using a database-driven website (and adequate server
bandwidth, which won't be a problem), I'm assuming this *wouldn't* be a
problem.

Larry


subject: [Wikipedia-l] Wikipedia publicity  by  the NYT?

body:
I thought I said something about this...maybe not.

I was interviewed by a NYT reporter on Tuesday or Wednesday.  Jimbo told
me is was going to be (perhaps already have been) interviewed as well.
The subject of the article is collaborative websites.  The reporter seemed
to take an interest in wikis generally.  I can't tell you how prominently
Wikipedia might feature in the article--it might just be one or two
sentences, but it seems odd that the reporter would call me first and
interview me for something like 45 minutes if it were just going to be one
or two sentences--and that he'd want to interview Jimbo as well.  My
totally unconfirmed suspicion is that Wikipedia might be *very*
prominently placed in a long feature article.

If so, Wikipedia is going to flooded with traffic--at least as much as
with the Slashdotting.  Very possibly more, because it's quite possible
that other news sources will pick the story up from the NYT, as often
happens.  This happened when Newsbytes and Computerworld picked up the
Nupedia story last year.

It's totally within the realm of possibility that we will have an order of
magnitude greater amount of traffic than we had during the Slashdotting.
Now, the server can probably handle even that (right, Jimbo?) but I have
my worries about the software.

Larry

On Fri, 24 Aug 2001, Tim Chambers wrote:

> lsanger at ross.bomis.com wrote:
> > Subject: Re: [Wikipedia-l] PHP Wikipedia
> > We don't know when the New York Times article is going to appear, but my
> > understanding is that it could be as early as next Tuesday.
>
> Then Jimbo wrote:
> >There's NO REASON to think that we need to hurry this because of the New
> York
> >Times article.
>
> I don't claim title to any special status as a Wikipedian, but I do closely
> follow Wikipedia-L and RecentChanges. This is the first I've heard of the
> NYT doing a piece on Wikipedia. Would someone in the know mind filling us
> proletariats in, please? :-)
>
> <>< Tim
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


body:
lsanger at ross.bomis.com wrote:
> Subject: Re: [Wikipedia-l] PHP Wikipedia
> We don't know when the New York Times article is going to appear, but my
> understanding is that it could be as early as next Tuesday.

Then Jimbo wrote:
>There's NO REASON to think that we need to hurry this because of the New
York
>Times article.

I don't claim title to any special status as a Wikipedian, but I do closely
follow Wikipedia-L and RecentChanges. This is the first I've heard of the
NYT doing a piece on Wikipedia. Would someone in the know mind filling us
proletariats in, please? :-)

<>< Tim


subject: [Wikipedia-l] PHP Wikipedia

body:
On Fri, 24 Aug 2001, Jimmy Wales wrote:

Wow, I'm glad to hear that the reporter might be featuring Wikipedia.
Great!

> The fact that this is a cgi script, rather than a fastcgi script, is a bottleneck,
> but conversion from cgi to fastcgi is (nearly) trivial, and I've got that ready
> to go.

Very cool!

> Also, the server running wikipedia has 512 meg of memory now, but we can quickly
> upgrade that to 2 gig if necessary.  (And memory is frighteningly cheap these
> days.)  Additional memory will be automatically used by the filesystem to cache
> frequently accessed files, etc., etc.
>
> It's all good.  My only concern is the edit locks.

OK.  Well, is there any way to take care of that problem by rewriting the
software?  What the hell IS an edit lock, anyway?

Showing my technical ignorance again,
Larry


body:
On Fri, 24 Aug 2001, Jimmy Wales wrote:
> > If so, Wikipedia is going to flooded with traffic--at least as much as
> > with the Slashdotting.
>
> I don't necessarily agree with this.  The NYT may be powerful, but it isn't
> exactly slashdot.  :-)

Yeah, but what if the article gets Slashdotted?  :-)  --Larry


subject: [Wikipedia-l] PHP Wikipedia

in_reply_to: <ILENJBCFHGHELEBFPPBGMECNCDAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Fri, Aug 24, 2001 at 09:45:34PM +0200

body:
How difficult do you think it will be to import all the existing wikipedia data
into your version?

What's your take on the general availability of PHP skills on the net, versus
Perl skills?

I've been talking to Clifford Adams about the future of Wikipedia and UseModWiki,
and he's given his blessing to a Wikipedia-centric fork of his code.  Some of the
design goals for UseModWiki, namely that it be easy to install, etc., aren't necessarily
consistent with some of the more highly specialized needs of Wikipedia.  He suggests
that we find someone (Magnus? :-)) to take over the forked version, and that we could
set up a modern CVS, etc.

I'm reluctant to go the PHP route, partially because I don't personally know much
about PHP, but if you can convince me that it's sufficiently superior to a mod_perl
or perl fastcgi solution, I'm thinking that we could go your route.  Your code could
be wikipedia-centric, and we could all learn to help you with it.

--Jimbo

Magnus Manske wrote:

> Hi all,
>
> as a few of you might know, I just wrote a complete (well, almost) Wikipedia
> software as a PHP script!
>
> It has all essential wiki features like article editing, version management,
> user management, subpages, etc.
> Additionally, its data storage is completely MySQL (fast!), it has a file
> upload tool, some other goodies soon.
> Maybe best of all, script and database are prepared to support some kind of
> editor/superuser functionality for "locking" pages, as it is currently
> discussed.
>
> Now to the bad sides (yes, there are some...)
> - I don't have a server to host it yet. Maybe I can run it on the Nupedia
> server sometimes. So, no trying yet, sorry.
> - The parser (to convert the source text into readable stuff) is very basic.
> I copied the HomePage and the SandBox from wikipedia, and they look about
> the same, but this is wherte the bugs will be.
> - Currently, I don't have a means to convert wikipedia to MySQL
> automatically, which is what would have to be done if (IF!) this script ever
> gets used.
>
> Just letting you know there's an early but working alternative ready...
>
> Magnus
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] PHP Wikipedia

in_reply_to: <ILENJBCFHGHELEBFPPBGKECOCDAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Fri, Aug 24, 2001 at 10:10:07PM +0200

body:
Magnus Manske wrote:
> I downloaded one of these traballs, but didn't look at it in detail, so I'm
> uncertain how complicated that would be. But if we're to move to MySQL
> anyway, either with my solution or a new CGI script, conversion is
> unavoidable.

Agreed.  I'm not sure why we want to move to MySQL, at least I'm not sure
why *in particular*, although I understand the general desirability of a
"real" database in general.

> Which is another thing I need to know. Should I implement a "rights
> management"? If yes, how? Probably group-based, with an "editor" group
> giving out special rights? And limits that can be changes for each page, or
> should that go by page name, like "/Talk is open to everyone, /Lock can only
> be changed by editors"? Please give me input on this!

I should think that by default all pages should be open to everyone.  If and when
we need locking capability, we can see what we need it for, and add it in a limited
way for that.

However, I personally will fight hard against the idea of locking *any* pages, with
the *possible* exception of some "meta" pages which talk about how the software
works, etc.  Even there, I don't see a good reason to lock the pages.

> BTW, who should I contact for testing my script and the DB on a "real"
> server? Toan? And should I make the script public now, so everyone can take
> a look? As a wiki article, or post it here on the list?

Contact jasonr at aristotle.bomis.com  I'll have him help you.

Yes, let's have a look at the script, it sounds fun!

> Finally, I'm not sure I can do the long-term of the script maintnance
> myself. I'll work on the rights management and bug-fixing until it runs
> without bugs, of course, and can fix minor things when they pop up. But in a
> few weeks/month, I'll be quite busy at university, and can't promise
> anything there.

*Nod*  I understand.  Since you wrote this initial version, and if we go with it
as a replacement for UseMod, I'm sure you'll be the main guy to oversee it for the
first few weeks.  If it is easy enough for other people to grasp what is going on,
it should be no problem for someone to step up to the plate to cover the role of
maintainer.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] PHP Wikipedia

body:
I can't speak to the general availability of PHP skills on the net, except
to say I've seen statistics that show that PHP the single most common Mod
for Apache with an  850,000 server installed base -- which is about over
three times mod pearl's 250,000.  Those statistics come form
www.secutityspace.com.  The exact web site is:

http://www.securityspace.com/s_survey/data/man.200107/apachemods.html

I have some basic skills with PHP and MySQL, and some experience with
PosgreSQL.  I'm no uberhacker, but I can throw together PHP code a lot
faster than pearl CGI, so I think PHP is a reasonable way to go.

I'll look into it, but I seem to remember seeing another PHP based WikiWiki
project out there, so we may have an existing code base to work with.
(Though it looks like Magnus may have done this for us as well...)

I think MySQL will be fine for a project like this, no matter whether we
choose PHP or Mod Pearl, but we should take a look at what we are likely to
need in the future before making a commitment to a particular database
backend.

-----Original Message-----
From: Jimmy Wales [mailto:jwales at bomis.com]
Sent: Friday, August 24, 2001 5:30 PM
To: wikipedia-l at nupedia.com
Subject: Re: [Wikipedia-l] PHP Wikipedia

How difficult do you think it will be to import all the existing wikipedia
data
into your version?

What's your take on the general availability of PHP skills on the net,
versus
Perl skills?

I've been talking to Clifford Adams about the future of Wikipedia and
UseModWiki,
and he's given his blessing to a Wikipedia-centric fork of his code.  Some
of the
design goals for UseModWiki, namely that it be easy to install, etc., aren't
necessarily
consistent with some of the more highly specialized needs of Wikipedia.  He
suggests
that we find someone (Magnus? :-)) to take over the forked version, and that
we could
set up a modern CVS, etc.

I'm reluctant to go the PHP route, partially because I don't personally know
much
about PHP, but if you can convince me that it's sufficiently superior to a
mod_perl
or perl fastcgi solution, I'm thinking that we could go your route.  Your
code could
be wikipedia-centric, and we could all learn to help you with it.

--Jimbo

Magnus Manske wrote:

> Hi all,
>
> as a few of you might know, I just wrote a complete (well, almost)
Wikipedia
> software as a PHP script!
>
> It has all essential wiki features like article editing, version
management,
> user management, subpages, etc.
> Additionally, its data storage is completely MySQL (fast!), it has a file
> upload tool, some other goodies soon.
> Maybe best of all, script and database are prepared to support some kind
of
> editor/superuser functionality for "locking" pages, as it is currently
> discussed.
>
> Now to the bad sides (yes, there are some...)
> - I don't have a server to host it yet. Maybe I can run it on the Nupedia
> server sometimes. So, no trying yet, sorry.
> - The parser (to convert the source text into readable stuff) is very
basic.
> I copied the HomePage and the SandBox from wikipedia, and they look about
> the same, but this is wherte the bugs will be.
> - Currently, I don't have a means to convert wikipedia to MySQL
> automatically, which is what would have to be done if (IF!) this script
ever
> gets used.
>
> Just letting you know there's an early but working alternative ready...
>
> Magnus
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************
[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


body:
Jimbo wrote:

> Also, we have a fastcgi version of the software ready to run if that
becomes
> necessary.  fastcgi is many many many times faster than cgi.

So what's the downside of doing it BEFORE it "becomes necessary"?

<>< Tim


subject: [Wikipedia-l] PHP Wikipedia

in_reply_to: <2100F5D84712D411A00E00B0D0221D1A20200C@kodiak.htec.com>; from mchristensen@htec.com on Fri, Aug 24, 2001 at 05:08:23PM -0400

body:
Mark Christensen wrote:
> I can't speak to the general availability of PHP skills on the net, except
> to say I've seen statistics that show that PHP the single most common Mod
> for Apache with an  850,000 server installed base -- which is about over
> three times mod pearl's 250,000.

O.k., I'm sold that this is a viable middle of the road technology.

> I have some basic skills with PHP and MySQL, and some experience with
> PosgreSQL.  I'm no uberhacker, but I can throw together PHP code a lot
> faster than pearl CGI, so I think PHP is a reasonable way to go.

That's great!  One of the most important things is that people shouldn't need
to be uberhackers in order to get involved.... it's the wiki spirit.  :-)

> I think MySQL will be fine for a project like this, no matter whether we
> choose PHP or Mod Pearl, but we should take a look at what we are likely to
> need in the future before making a commitment to a particular database
> backend.

I think that as long as we are careful to stick to "standard" SQL commands, and
not use any that are special to mysql, it is easy to switch to a different backend
(Postgres for example) if and when we need to do so.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] Edit locks

body:
Given your analysis, the idea of "per-file" edit locks sounds good to me.
If that could be put together quickly, that would be great.  But you don't
sound quite sure that there's no significant risk if we were just to remove
the edit locks altogether.  I mean, what does a "collision" involve?

Larry

----- Original Message -----
From: "Jimmy Wales" <jwales at bomis.com>
To: <wikipedia-l at nupedia.com>
Sent: Friday, August 24, 2001 6:20 PM
Subject: [Wikipedia-l] Edit locks

> Here's my understanding of the edit lock problem...
>
> Whenever someone is actively in the process of writing their changes to
disk,
> the software makes a temporary file (directory) on the disk to let other
instances
> of the cgi process know that this one is doing some writing to disk.  You
don't
> want two processes to write to the same file at the same time, because you
will
> lose one person's changes and possibly the entire file.
>
> Notice that the edit lock is only there when you are *actively writing
your changes
> to disk*.  This isn't while you are typing them, but only for that instant
after
> you hit 'submit' and before you get the next screen back.
>
> The problem is that -- for mysterious reasons -- the script sometimes dies
and leaves
> the edit lock hanging.  All other processes after that refuse to write
changes to disk
> because they think that someone has the edit lock.
>
> There are several possible solutions.  My own personal solution is wild.
I just
> wouldn't use a lock at all.  You run the risk of collisions, but these are
so rare
> *in my experience* as to be worth ignoring.
>
> Another solution is to have 'per-file' edit locks.  This is more elegant,
because
> there isn't any particular reason to lock the ENTIRE system down just
because one
> person is writing to one file.  If Larry is writing to file A and I am
writing to file
> B, there is no reason to lock anything.  The main downside to this
solution is that
> it is still possible for an edit lock to get hung.  The good thing is that
only one
> page would be affected, not the entire site.
>
> Another solution is to find the reason why the script is leaving the lock,
and fix
> that bug.  In my experience, this will be impossible.  CGI scripts do in
fact die
> for no apparent reason sometimes, and it's very hard to trap/debug/etc.  I
mean, it
> is theoretically possible, but as a practical matter I find that something
is always
> left hanging.
>
> One of my own personal design philosophies is that everything should fail
gracefully.
> That is, I accept that my own software sucks and will in fact break.  This
is a matter
> of humility before the gods of software.  The best that I can hope for is
that when my
> software does choke, it will do so gracefully.  There will always be bugs
and things
> that don't work right, but as long as they don't destroy the universe,
there's hope.
>
> :-)
>
> --Jimbo
>
>
>
>
> --
> *************************************************
> *            http://www.nupedia.com/            *
> *      The Ever Expanding Free Encyclopedia     *
> *************************************************
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Kaki Nix Sain

subject: [Wikipedia-l] google indexing

body:
hey,
	I recently read that google has implemented a system that learns,
to some approximate degree, how often a site is changed and then starts to
reindex that site according to what it has learned.  I don't know much
more about it than that, but if this rumor is true, than the problem with
them only indexing wikipedia once a month should go away in time.  Someone
could write and ask them about this.

me

> Message: 7
> Date:   Fri, 24 Aug 2001 15:35:31 +0200 (MET DST)
> From: Axel Boldt <axel at uni-paderborn.de>
> To: wikipedial-l at nupedia.com
> Subject: [Wikipedia-l] Searching with Google
> Reply-To: wikipedia-l at nupedia.com
>
> Hi,
>
> I think Tim's Google trick is really cool and until we have a better
> search engine ourselves, we should definitely put a search box like
> his on our home page.
>
> The only downside is that Google indexes our site only once a month.
>
> On my sites, I have in the past used http://htdig.org. The search
> results are just as fast and precise as google's, but you control when
> and what you index. A cron script once a night should be fine.
>
> Axel


subject: [Wikipedia-l] PHP Wikipedia

body:
lsanger at ross.bomis.com wrote:
> No, the best thing of all would be something that can instantly and
> *without loss of data or format* transfer Wikipedia pages from UseModWiki
> into Wikipedia code.  We could call this Encyclode (encyclopedia + code).
> On the other hand, that might be lame.  That's just my idea.  :-)

My lame name suggestion is Pediawiki.  "Which wiki software does wikipedia
run?  Wikipedia runs Pediawiki!  It's the wiki software designed for encyclopedias!"

> Jimbo mentioned the possibility of a CVS system--wouldn't take long to set
> up.  Unfortunately, it's Friday afternoon...

Yes, probably Monday morning we can set this up.

There's NO REASON to think that we need to hurry this because of the New York
Times article.  Our current site will easily survive the load of that, especially
after I finish speeding up the search engine (later this afternoon, cross your
fingers).

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


body:
lsanger at ross.bomis.com wrote:
> I was interviewed by a NYT reporter on Tuesday or Wednesday.  Jimbo told
> me is was going to be (perhaps already have been) interviewed as well.

Yes.  The reporter clarified that he is a freelancer, but the piece will appear
in the NYT.  He suggested to me that Wikipedia might well be the focus of the
article.

> If so, Wikipedia is going to flooded with traffic--at least as much as
> with the Slashdotting.

I don't necessarily agree with this.  The NYT may be powerful, but it isn't
exactly slashdot.  :-)

> It's totally within the realm of possibility that we will have an order of
> magnitude greater amount of traffic than we had during the Slashdotting.
> Now, the server can probably handle even that (right, Jimbo?) but I have
> my worries about the software.

Yes, the server can handle that, but we'll probably have edit lock problems.
We have a cron job to clear those, though, and I plan to make the instructions
for peopel to clear it themselves more clear before the article appears.

Also, we have a fastcgi version of the software ready to run if that becomes
necessary.  fastcgi is many many many times faster than cgi.

--Jimbo

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] PHP Wikipedia

body:
lsanger at ross.bomis.com wrote:
> (4) Isn't it possible that, with a lot of traffic, the whole website will
> just become unusably slow because it's based on text files?  I am asking
> out of pure ignorance and blind fear, and need to be educated on this
> point.  If we were using a database-driven website (and adequate server
> bandwidth, which won't be a problem), I'm assuming this *wouldn't* be a
> problem.

Bomis handles roughly 500 times the traffic of wikipedia with text files.
The text files are not a bottleneck.  They get cached by the filesystem.

The fact that this is a cgi script, rather than a fastcgi script, is a bottleneck,
but conversion from cgi to fastcgi is (nearly) trivial, and I've got that ready
to go.

Also, the server running wikipedia has 512 meg of memory now, but we can quickly
upgrade that to 2 gig if necessary.  (And memory is frighteningly cheap these
days.)  Additional memory will be automatically used by the filesystem to cache
frequently accessed files, etc., etc.

It's all good.  My only concern is the edit locks.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


in_reply_to: <013001c12cf3$5e22d260$80441d82@cos.agilent.com>; from tbc+wikipedia@cos.agilent.com on Fri, Aug 24, 2001 at 05:20:29PM -0600

body:
Not much.  It's just a matter of doing it.  I'll try to get to it this
weekend.

Tim Chambers wrote:

> Jimbo wrote:
>
> > Also, we have a fastcgi version of the software ready to run if that
> becomes
> > necessary.  fastcgi is many many many times faster than cgi.
>
> So what's the downside of doing it BEFORE it "becomes necessary"?
>
> <>< Tim
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] Edit locks

body:
Here's my understanding of the edit lock problem...

Whenever someone is actively in the process of writing their changes to disk,
the software makes a temporary file (directory) on the disk to let other instances
of the cgi process know that this one is doing some writing to disk.  You don't
want two processes to write to the same file at the same time, because you will
lose one person's changes and possibly the entire file.

Notice that the edit lock is only there when you are *actively writing your changes
to disk*.  This isn't while you are typing them, but only for that instant after
you hit 'submit' and before you get the next screen back.

The problem is that -- for mysterious reasons -- the script sometimes dies and leaves
the edit lock hanging.  All other processes after that refuse to write changes to disk
because they think that someone has the edit lock.

There are several possible solutions.  My own personal solution is wild.  I just
wouldn't use a lock at all.  You run the risk of collisions, but these are so rare
*in my experience* as to be worth ignoring.

Another solution is to have 'per-file' edit locks.  This is more elegant, because
there isn't any particular reason to lock the ENTIRE system down just because one
person is writing to one file.  If Larry is writing to file A and I am writing to file
B, there is no reason to lock anything.  The main downside to this solution is that
it is still possible for an edit lock to get hung.  The good thing is that only one
page would be affected, not the entire site.

Another solution is to find the reason why the script is leaving the lock, and fix
that bug.  In my experience, this will be impossible.  CGI scripts do in fact die
for no apparent reason sometimes, and it's very hard to trap/debug/etc.  I mean, it
is theoretically possible, but as a practical matter I find that something is always
left hanging.

One of my own personal design philosophies is that everything should fail gracefully.
That is, I accept that my own software sucks and will in fact break.  This is a matter
of humility before the gods of software.  The best that I can hope for is that when my
software does choke, it will do so gracefully.  There will always be bugs and things
that don't work right, but as long as they don't destroy the universe, there's hope.

:-)

--Jimbo

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


from_name: Magnus Manske

subject: [Wikipedia-l] PHP Wikipedia

body:
Hi all,

as a few of you might know, I just wrote a complete (well, almost) Wikipedia
software as a PHP script!

It has all essential wiki features like article editing, version management,
user management, subpages, etc.
Additionally, its data storage is completely MySQL (fast!), it has a file
upload tool, some other goodies soon.
Maybe best of all, script and database are prepared to support some kind of
editor/superuser functionality for "locking" pages, as it is currently
discussed.

Now to the bad sides (yes, there are some...)
- I don't have a server to host it yet. Maybe I can run it on the Nupedia
server sometimes. So, no trying yet, sorry.
- The parser (to convert the source text into readable stuff) is very basic.
I copied the HomePage and the SandBox from wikipedia, and they look about
the same, but this is wherte the bugs will be.
- Currently, I don't have a means to convert wikipedia to MySQL
automatically, which is what would have to be done if (IF!) this script ever
gets used.

Just letting you know there's an early but working alternative ready...

Magnus


subject: [Wikipedia-l] PHP Wikipedia

body:
I downloaded one of these traballs, but didn't look at it in detail, so I'm
uncertain how complicated that would be. But if we're to move to MySQL
anyway, either with my solution or a new CGI script, conversion is
unavoidable.

I guess there are enough people out there who know some PHP, and it's easy
to learn (easier than CGI, I think). As you know, Nupedia is PHP-based, and
it works quite well. The script could also become a wikipedia "article"
itself, which can be copied to a real file after an upgrade or error
correction. It might be a good idea to limit write access to that "article",
though. That could make a CVS unnecessary.

Which is another thing I need to know. Should I implement a "rights
management"? If yes, how? Probably group-based, with an "editor" group
giving out special rights? And limits that can be changes for each page, or
should that go by page name, like "/Talk is open to everyone, /Lock can only
be changed by editors"? Please give me input on this!

BTW, who should I contact for testing my script and the DB on a "real"
server? Toan? And should I make the script public now, so everyone can take
a look? As a wiki article, or post it here on the list?

Oh, so many questions...

Finally, I'm not sure I can do the long-term of the script maintnance
myself. I'll work on the rights management and bug-fixing until it runs
without bugs, of course, and can fix minor things when they pop up. But in a
few weeks/month, I'll be quite busy at university, and can't promise
anything there.

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Jimmy Wales
> Sent: Friday, August 24, 2001 11:30 PM
> To: wikipedia-l at nupedia.com
> Subject: Re: [Wikipedia-l] PHP Wikipedia
>
>
> How difficult do you think it will be to import all the existing
> wikipedia data
> into your version?
>
> What's your take on the general availability of PHP skills on the
> net, versus
> Perl skills?
>
> I've been talking to Clifford Adams about the future of Wikipedia
> and UseModWiki,
> and he's given his blessing to a Wikipedia-centric fork of his
> code.  Some of the
> design goals for UseModWiki, namely that it be easy to install,
> etc., aren't necessarily
> consistent with some of the more highly specialized needs of
> Wikipedia.  He suggests
> that we find someone (Magnus? :-)) to take over the forked
> version, and that we could
> set up a modern CVS, etc.
>
> I'm reluctant to go the PHP route, partially because I don't
> personally know much
> about PHP, but if you can convince me that it's sufficiently
> superior to a mod_perl
> or perl fastcgi solution, I'm thinking that we could go your
> route.  Your code could
> be wikipedia-centric, and we could all learn to help you with it.
>
> --Jimbo
>
>
> Magnus Manske wrote:
>
> > Hi all,
> >
> > as a few of you might know, I just wrote a complete (well,
> almost) Wikipedia
> > software as a PHP script!
> >
> > It has all essential wiki features like article editing,
> version management,
> > user management, subpages, etc.
> > Additionally, its data storage is completely MySQL (fast!), it
> has a file
> > upload tool, some other goodies soon.
> > Maybe best of all, script and database are prepared to support
> some kind of
> > editor/superuser functionality for "locking" pages, as it is currently
> > discussed.
> >
> > Now to the bad sides (yes, there are some...)
> > - I don't have a server to host it yet. Maybe I can run it on
> the Nupedia
> > server sometimes. So, no trying yet, sorry.
> > - The parser (to convert the source text into readable stuff)
> is very basic.
> > I copied the HomePage and the SandBox from wikipedia, and they
> look about
> > the same, but this is wherte the bugs will be.
> > - Currently, I don't have a means to convert wikipedia to MySQL
> > automatically, which is what would have to be done if (IF!)
> this script ever
> > gets used.
> >
> > Just letting you know there's an early but working alternative ready...
> >
> > Magnus
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
> --
> *************************************************
> *            http://www.nupedia.com/            *
> *      The Ever Expanding Free Encyclopedia     *
> *************************************************
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Edit locks

body:
Peter Jones wrote:
> As for removing the locks altogether -- well, any Discworld readers care to
> point out how often the "million to one chance of a collision" would occur?

Oooh, do tell, a horror story?  I love those!

In this case, if there were no locks and the "million to one chance of a collision"
occurred, the worst that can happen is that one article gets corrupted.

That's bad, of course, but the edit lock problem persists in being persistently
annoying.

It might be a lot better if I just looked into a 'one lock per article' solution.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] PHP Wikipedia, Part 2

body:
Jason is activating php.wikipedia.com for the script to test, which should
be working later today. So, soon you can flood me with bug reports ;)

Some points that were mentioned on the list while I was asleep:
- Larry, I don't oppose CVS as such, I just thought why bother...
  So, I wouldn't mind a CVS at all.

- Edit locks : I thought they'd protect a page that is edited for a certain
time, e.g., 5 minutes, so there won't be two edits of the same text at the
same time. Now that I know it's only for writing, I am glad to not have
wasted time in implementing such a thing in my script ;)
  The MySQL server will take care of the write-at-the-same-time problem, for
sure.

- /Talk pages : Changing the standard text for new documents so they'd have
a /Talk page should do it, right? I could also have the parser look for
"/Talk" and append it if necessary in a "top-level" article.

- Conversion to SQL format : The easiest way I can think of is a script that
goes through all articles in the current wikipedia and generates a complete
article text in chronoligical order (oldest first). After each "version" is
generated, a variant of my script can store it in the DB. That would ensure
identical data. Anyone to write a "generation" script?

- Lame names : How about "Aide-Pikiw" (wikipedia spelled backwards)? That
must be the lamest, for sure? ;)

Magnus


subject: [Wikipedia-l] Edit locks

body:
At 10:58 AM 8/25/01, you wrote:
>Given your analysis, the idea of "per-file" edit locks sounds good to me.
>If that could be put together quickly, that would be great.  But you don't
>sound quite sure that there's no significant risk if we were just to remove
>the edit locks altogether.  I mean, what does a "collision" involve?

FWIW, if there *is* a push to move the Wikipedia across to MySQL, I believe
that table write locking can be handled fairly easily by the database --
and that if a write request comes in while a table is write locked, it is
simply queued to be performed once the table is available again.  Of
course, my programming experience with PHP and MySQL is not particularly
extensive, and I've never really had to deal with a multi-user system, so
maybe I'm just wrong.

Anyone?

As for removing the locks altogether -- well, any Discworld readers care to
point out how often the "million to one chance of a collision" would occur?

Pete.


subject: [Wikipedia-l] PHP Wikipedia, Part 2

body:
If anyone ever uploads an Internet-accessible version of the wiki, I'd
sure like to see it.

Larry

On Sat, 25 Aug 2001, Mark Christensen wrote:

> I've been tooling around on the php wikipedia, and it is very nice!
> Congratulations.
>
> Great job with the statistics page, it'll be very useful.
>
> The parser works well with the couple pages I imported, generally I'm very
> impressed.
>
> Are you planning to post the code for this on one of the php.wikipedia.com
> pages as you mentioned in a previous e-mail.  I'd be very interested in
> seeing it.
>
> The one problem I see thus far is that UseModWiki allows subpage links on a
> subpage to other subpages of the main page.  I know that's not the best
> description, but in the original wikipedia software a [[/subtalk]] link on
> [[MainPage/talk]] would lead to [[MainPage/subtalk]].  We may not want to
> emulate this, as it is certainly not intuitive, but there are a lot of
> pages, like poker, with subpages that link to other subpages -- either our
> parser needs to automatically translate these links or the PHP wikipedia
> should deal with them in the same way as UseModWiki.
>
> Yours
> Mark Christensen
>
> -----Original Message-----
> From: Magnus Manske [mailto:Magnus.Manske at epost.de]
> Sent: Saturday, August 25, 2001 3:30 AM
> To: Wikipedia-L at Nupedia. Com
> Subject: [Wikipedia-l] PHP Wikipedia, Part 2
>
>
> Jason is activating php.wikipedia.com for the script to test, which should
> be working later today. So, soon you can flood me with bug reports ;)
>
> Some points that were mentioned on the list while I was asleep:
> - Larry, I don't oppose CVS as such, I just thought why bother...
>   So, I wouldn't mind a CVS at all.
>
> - Edit locks : I thought they'd protect a page that is edited for a certain
> time, e.g., 5 minutes, so there won't be two edits of the same text at the
> same time. Now that I know it's only for writing, I am glad to not have
> wasted time in implementing such a thing in my script ;)
>   The MySQL server will take care of the write-at-the-same-time problem, for
> sure.
>
> - /Talk pages : Changing the standard text for new documents so they'd have
> a /Talk page should do it, right? I could also have the parser look for
> "/Talk" and append it if necessary in a "top-level" article.
>
> - Conversion to SQL format : The easiest way I can think of is a script that
> goes through all articles in the current wikipedia and generates a complete
> article text in chronoligical order (oldest first). After each "version" is
> generated, a variant of my script can store it in the DB. That would ensure
> identical data. Anyone to write a "generation" script?
>
> - Lame names : How about "Aide-Pikiw" (wikipedia spelled backwards)? That
> must be the lamest, for sure? ;)
>
> Magnus
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] PHP Wikipedia, Part 2

body:
I am putting some comments on
http://php.wikipedia.com/niki.phtml?title=Larry_Sanger&action=view

I have lots of comments.  :-)

Larry

On Sat, 25 Aug 2001, Magnus Manske wrote:

> Sorry, I forgot. I hereby put my script under GNU licence.
>
> Magnus
>
> > -----Original Message-----
> > From: wikipedia-l-admin at nupedia.com
> > [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Mark Christensen
> > Sent: Saturday, August 25, 2001 9:20 PM
> > To: 'wikipedia-l at nupedia.com'
> > Subject: RE: [Wikipedia-l] PHP Wikipedia, Part 2
> >
> >
> > Magnus's PHP version of the Wikipedia is now available at:
> >
> > Http://php.wikipedia.com/
> >
> > You can also find another PHP and MySQL version of the WikiWiki
> > software in
> > use at:
> >
> > http://phpwiki.sourceforge.net/phpwiki/
> >
> > Perhaps we might be able to get some ideas and/or code from these guys.  I
> > don't know what license Magnus's version has, but the phpwiki at the above
> > link is GPLed, and has some useful features which we might want
> > to implement
> > on our own PHP wiki.  One such feature, which has been very
> > useful to me on
> > the current UseModWiki based version of WikiPedia is DIFF.
> >
> > Anyway, I now see that the code for Magnus's version is up, so I can look
> > more closely at the differences...
> >
> > -----Original Message-----
> > From: lsanger at ross.bomis.com [mailto:lsanger at ross.bomis.com]
> > Sent: Saturday, August 25, 2001 3:05 PM
> > To: 'wikipedia-l at nupedia.com'
> > Subject: RE: [Wikipedia-l] PHP Wikipedia, Part 2
> >
> >
> > If anyone ever uploads an Internet-accessible version of the wiki, I'd
> > sure like to see it.
> >
> > Larry
> >
> > On Sat, 25 Aug 2001, Mark Christensen wrote:
> >
> > > I've been tooling around on the php wikipedia, and it is very nice!
> > > Congratulations.
> > >
> > > Great job with the statistics page, it'll be very useful.
> > >
> > > The parser works well with the couple pages I imported,
> > generally I'm very
> > > impressed.
> > >
> > > Are you planning to post the code for this on one of the
> > php.wikipedia.com
> > > pages as you mentioned in a previous e-mail.  I'd be very interested in
> > > seeing it.
> > >
> > > The one problem I see thus far is that UseModWiki allows
> > subpage links on
> > a
> > > subpage to other subpages of the main page.  I know that's not the best
> > > description, but in the original wikipedia software a
> > [[/subtalk]] link on
> > > [[MainPage/talk]] would lead to [[MainPage/subtalk]].  We may
> > not want to
> > > emulate this, as it is certainly not intuitive, but there are a lot of
> > > pages, like poker, with subpages that link to other subpages --
> > either our
> > > parser needs to automatically translate these links or the PHP wikipedia
> > > should deal with them in the same way as UseModWiki.
> > >
> > > Yours
> > > Mark Christensen
> > >
> > > -----Original Message-----
> > > From: Magnus Manske [mailto:Magnus.Manske at epost.de]
> > > Sent: Saturday, August 25, 2001 3:30 AM
> > > To: Wikipedia-L at Nupedia. Com
> > > Subject: [Wikipedia-l] PHP Wikipedia, Part 2
> > >
> > >
> > > Jason is activating php.wikipedia.com for the script to test,
> > which should
> > > be working later today. So, soon you can flood me with bug reports ;)
> > >
> > > Some points that were mentioned on the list while I was asleep:
> > > - Larry, I don't oppose CVS as such, I just thought why bother...
> > >   So, I wouldn't mind a CVS at all.
> > >
> > > - Edit locks : I thought they'd protect a page that is edited for a
> > certain
> > > time, e.g., 5 minutes, so there won't be two edits of the same
> > text at the
> > > same time. Now that I know it's only for writing, I am glad to not have
> > > wasted time in implementing such a thing in my script ;)
> > >   The MySQL server will take care of the write-at-the-same-time problem,
> > for
> > > sure.
> > >
> > > - /Talk pages : Changing the standard text for new documents so they'd
> > have
> > > a /Talk page should do it, right? I could also have the parser look for
> > > "/Talk" and append it if necessary in a "top-level" article.
> > >
> > > - Conversion to SQL format : The easiest way I can think of is a script
> > that
> > > goes through all articles in the current wikipedia and generates a
> > complete
> > > article text in chronoligical order (oldest first). After each "version"
> > is
> > > generated, a variant of my script can store it in the DB. That would
> > ensure
> > > identical data. Anyone to write a "generation" script?
> > >
> > > - Lame names : How about "Aide-Pikiw" (wikipedia spelled
> > backwards)? That
> > > must be the lamest, for sure? ;)
> > >
> > > Magnus
> > >
> > > [Wikipedia-l]
> > > To manage your subscription to this list, please go here:
> > > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> > > [Wikipedia-l]
> > > To manage your subscription to this list, please go here:
> > > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> > >
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] My comments on that Magnificent coding

body:
("Magnificent" is an adjective meaning "of Magnus"--get it?)

I have listed some issues with the code that I found, on:
http://php.wikipedia.com/niki.phtml?title=Pediawiki_bugs&action=view

Larry


subject: [Wikipedia-l] PHP Wikipedia, Part 2

body:
I've been tooling around on the php wikipedia, and it is very nice!
Congratulations.

Great job with the statistics page, it'll be very useful.

The parser works well with the couple pages I imported, generally I'm very
impressed.

Are you planning to post the code for this on one of the php.wikipedia.com
pages as you mentioned in a previous e-mail.  I'd be very interested in
seeing it.

The one problem I see thus far is that UseModWiki allows subpage links on a
subpage to other subpages of the main page.  I know that's not the best
description, but in the original wikipedia software a [[/subtalk]] link on
[[MainPage/talk]] would lead to [[MainPage/subtalk]].  We may not want to
emulate this, as it is certainly not intuitive, but there are a lot of
pages, like poker, with subpages that link to other subpages -- either our
parser needs to automatically translate these links or the PHP wikipedia
should deal with them in the same way as UseModWiki.

Yours
Mark Christensen

-----Original Message-----
From: Magnus Manske [mailto:Magnus.Manske at epost.de]
Sent: Saturday, August 25, 2001 3:30 AM
To: Wikipedia-L at Nupedia. Com
Subject: [Wikipedia-l] PHP Wikipedia, Part 2

Jason is activating php.wikipedia.com for the script to test, which should
be working later today. So, soon you can flood me with bug reports ;)

Some points that were mentioned on the list while I was asleep:
- Larry, I don't oppose CVS as such, I just thought why bother...
  So, I wouldn't mind a CVS at all.

- Edit locks : I thought they'd protect a page that is edited for a certain
time, e.g., 5 minutes, so there won't be two edits of the same text at the
same time. Now that I know it's only for writing, I am glad to not have
wasted time in implementing such a thing in my script ;)
  The MySQL server will take care of the write-at-the-same-time problem, for
sure.

- /Talk pages : Changing the standard text for new documents so they'd have
a /Talk page should do it, right? I could also have the parser look for
"/Talk" and append it if necessary in a "top-level" article.

- Conversion to SQL format : The easiest way I can think of is a script that
goes through all articles in the current wikipedia and generates a complete
article text in chronoligical order (oldest first). After each "version" is
generated, a variant of my script can store it in the DB. That would ensure
identical data. Anyone to write a "generation" script?

- Lame names : How about "Aide-Pikiw" (wikipedia spelled backwards)? That
must be the lamest, for sure? ;)

Magnus

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] PHP Wikipedia, Part 2

body:
Magnus's PHP version of the Wikipedia is now available at:

Http://php.wikipedia.com/

You can also find another PHP and MySQL version of the WikiWiki software in
use at:

http://phpwiki.sourceforge.net/phpwiki/

Perhaps we might be able to get some ideas and/or code from these guys.  I
don't know what license Magnus's version has, but the phpwiki at the above
link is GPLed, and has some useful features which we might want to implement
on our own PHP wiki.  One such feature, which has been very useful to me on
the current UseModWiki based version of WikiPedia is DIFF.

Anyway, I now see that the code for Magnus's version is up, so I can look
more closely at the differences...

-----Original Message-----
From: lsanger at ross.bomis.com [mailto:lsanger at ross.bomis.com]
Sent: Saturday, August 25, 2001 3:05 PM
To: 'wikipedia-l at nupedia.com'
Subject: RE: [Wikipedia-l] PHP Wikipedia, Part 2

If anyone ever uploads an Internet-accessible version of the wiki, I'd
sure like to see it.

Larry

On Sat, 25 Aug 2001, Mark Christensen wrote:

> I've been tooling around on the php wikipedia, and it is very nice!
> Congratulations.
>
> Great job with the statistics page, it'll be very useful.
>
> The parser works well with the couple pages I imported, generally I'm very
> impressed.
>
> Are you planning to post the code for this on one of the php.wikipedia.com
> pages as you mentioned in a previous e-mail.  I'd be very interested in
> seeing it.
>
> The one problem I see thus far is that UseModWiki allows subpage links on
a
> subpage to other subpages of the main page.  I know that's not the best
> description, but in the original wikipedia software a [[/subtalk]] link on
> [[MainPage/talk]] would lead to [[MainPage/subtalk]].  We may not want to
> emulate this, as it is certainly not intuitive, but there are a lot of
> pages, like poker, with subpages that link to other subpages -- either our
> parser needs to automatically translate these links or the PHP wikipedia
> should deal with them in the same way as UseModWiki.
>
> Yours
> Mark Christensen
>
> -----Original Message-----
> From: Magnus Manske [mailto:Magnus.Manske at epost.de]
> Sent: Saturday, August 25, 2001 3:30 AM
> To: Wikipedia-L at Nupedia. Com
> Subject: [Wikipedia-l] PHP Wikipedia, Part 2
>
>
> Jason is activating php.wikipedia.com for the script to test, which should
> be working later today. So, soon you can flood me with bug reports ;)
>
> Some points that were mentioned on the list while I was asleep:
> - Larry, I don't oppose CVS as such, I just thought why bother...
>   So, I wouldn't mind a CVS at all.
>
> - Edit locks : I thought they'd protect a page that is edited for a
certain
> time, e.g., 5 minutes, so there won't be two edits of the same text at the
> same time. Now that I know it's only for writing, I am glad to not have
> wasted time in implementing such a thing in my script ;)
>   The MySQL server will take care of the write-at-the-same-time problem,
for
> sure.
>
> - /Talk pages : Changing the standard text for new documents so they'd
have
> a /Talk page should do it, right? I could also have the parser look for
> "/Talk" and append it if necessary in a "top-level" article.
>
> - Conversion to SQL format : The easiest way I can think of is a script
that
> goes through all articles in the current wikipedia and generates a
complete
> article text in chronoligical order (oldest first). After each "version"
is
> generated, a variant of my script can store it in the DB. That would
ensure
> identical data. Anyone to write a "generation" script?
>
> - Lame names : How about "Aide-Pikiw" (wikipedia spelled backwards)? That
> must be the lamest, for sure? ;)
>
> Magnus
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] PHP Wikipedia, Part 2

body:
Thanks a lot, I'm happy you like it. I was already smelling the eggs thrown
at me in my mind ;)

Hey Larry, just saw your mail - it's up at php.wikipedia.com !

AND, I uploaded the PHP source to wikipedia (just to be safe...) under
[[Wikipedia PHP script]].

Now the bad news (well, not bad for me...) : I am on short-notice vacation,
starting toworrow, for about a week. Sorry, but this was last-minute, and
there's no other time slot I could take.

I hope you'll manage without me for a few days (unbelievable!). I'll try to
stay in contact.

So far,
Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Mark Christensen
> Sent: Saturday, August 25, 2001 8:52 PM
> To: 'wikipedia-l at nupedia.com'
> Subject: RE: [Wikipedia-l] PHP Wikipedia, Part 2
>
>
> I've been tooling around on the php wikipedia, and it is very nice!
> Congratulations.
>
> Great job with the statistics page, it'll be very useful.
>
> The parser works well with the couple pages I imported, generally I'm very
> impressed.
>
> Are you planning to post the code for this on one of the php.wikipedia.com
> pages as you mentioned in a previous e-mail.  I'd be very interested in
> seeing it.
>
> The one problem I see thus far is that UseModWiki allows subpage
> links on a
> subpage to other subpages of the main page.  I know that's not the best
> description, but in the original wikipedia software a [[/subtalk]] link on
> [[MainPage/talk]] would lead to [[MainPage/subtalk]].  We may not want to
> emulate this, as it is certainly not intuitive, but there are a lot of
> pages, like poker, with subpages that link to other subpages -- either our
> parser needs to automatically translate these links or the PHP wikipedia
> should deal with them in the same way as UseModWiki.
>
> Yours
> Mark Christensen
>
> -----Original Message-----
> From: Magnus Manske [mailto:Magnus.Manske at epost.de]
> Sent: Saturday, August 25, 2001 3:30 AM
> To: Wikipedia-L at Nupedia. Com
> Subject: [Wikipedia-l] PHP Wikipedia, Part 2
>
>
> Jason is activating php.wikipedia.com for the script to test, which should
> be working later today. So, soon you can flood me with bug reports ;)
>
> Some points that were mentioned on the list while I was asleep:
> - Larry, I don't oppose CVS as such, I just thought why bother...
>   So, I wouldn't mind a CVS at all.
>
> - Edit locks : I thought they'd protect a page that is edited for
> a certain
> time, e.g., 5 minutes, so there won't be two edits of the same text at the
> same time. Now that I know it's only for writing, I am glad to not have
> wasted time in implementing such a thing in my script ;)
>   The MySQL server will take care of the write-at-the-same-time
> problem, for
> sure.
>
> - /Talk pages : Changing the standard text for new documents so
> they'd have
> a /Talk page should do it, right? I could also have the parser look for
> "/Talk" and append it if necessary in a "top-level" article.
>
> - Conversion to SQL format : The easiest way I can think of is a
> script that
> goes through all articles in the current wikipedia and generates
> a complete
> article text in chronoligical order (oldest first). After each
> "version" is
> generated, a variant of my script can store it in the DB. That
> would ensure
> identical data. Anyone to write a "generation" script?
>
> - Lame names : How about "Aide-Pikiw" (wikipedia spelled backwards)? That
> must be the lamest, for sure? ;)
>
> Magnus
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l