(Dropped off the list. Hmm, I notice there's no "reply-to" header on
wikitech-l messages like there is on wikipedia-l. Is this what's
tripping people up?)
Yes, that's probably it. Jimbo, would you please see that
my reply to you gets posted?
0
(Dropped off the list. Hmm, I notice there's no "reply-to" header on
wikitech-l messages like there is on wikipedia-l. Is this what's
tripping people up?)
-----Forwarded Message-----
From: lcrocker(a)nupedia.com
To: BrionL. VIBBER <brion(a)pobox.com>
Subject: Re: [Intlwiki-l] Re: [Wikitech-l] php-wiki de
Date: 23 May 2002 10:09:01 -0700
>> Perhaps we should considering moving to PostgreSQL which
>> really supports UTF-8...
> Oh, it's not like that hasn't been suggested. If anybody knows
> how to go about switching to Postgres, I sure as heck wouldn't
> object...
I'll look into installing it at Piclab so we can test it.
0
I did send a reply to Alex last night--something seems to have
dropped it on the floor; I don't know if it's on my side or the
list software. Brion's mail seems to imply the latter, but
since it hasn't happened to me other times that I rememeber,
I'll reserve judgment.
At any rate, thanks, Alex, for pointing out that my new namespace
fields were not indexed. I also strongly agree that NOW is
exactly the right time to think about tweaking the database
structure--all the infrastructure is in place now, but little
of the hairy structure-sensitive code of the special pages is
written, and the new codebase is well-enough encapsulated that
making database changes should be easy. Finally, the new code
already requires a database upgrade, so that's no excuse not to
do other useful changes. I'm updating the conversion script as
as I go.
To test my assumption of encapsulation I did in fact replace the
namespace fields in both the "cur" and "old" tables with integers.
This should keep the database smaller and speed it up. Making the
change took a lot less time than updating the database itself, so
it looks like the new codebase passed that test.
I'm also not thrilled with the linked/unliked tables. I'm thinking
of replacing them with a single "X links to Y" table using integer
indexes.
I'm also open to suggestions about how to change cur_ind_title.
Finally, I mostly agree with Axel's contention that "approval"
of articles is just metadata--the piece of information that person
X approved of article Y should just be stored somewhere, and used
when needed to make collections or whatever. I would call the
users authorized to make such approvals "editors", rather than
"sysops"--the latter seems more like the folks who can do techie
things like direct database access, etc.
Doing that would be easier with yet another database change I
considered earlier--replacing the odd linked-list mechanism of
old page versions seems awkward. It could be replaced by simply
using revision numbers that would be common to both the "cur" and
"old" tables. Or an even more radical change--merge both of those
tables in to one, and create a "current_revision" table. Ideas?
--
Lee Daniel Crocker <lee(a)piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
Since Lee added a namespace field, I think now is the time to
brainstorm and see if any other changes to the database scheme are
needed or desirable.
First, I think the cur_namespace should be indexed, since we are using
it for finding articles. Should old also get a an old_namespace, or do
you intend to store the namespace as part of the title? Also, I was
wondering about the cur_title/cur_ind_title situation. Would it be
possible to declare cur_title not as binary and combine the two?
Should we store the passwords in user in encrypted form? (Right now,
any sysop with mysql access can read all passwords.) Maybe we
should store the user_rights as a bitstring?
The tables linked, unlinked and ipblocks should have PACK_KEYS=1
(makes reads faster and updates slower). Any other possible fields for
site_stats? Maybe a date field?
Axel
(Messages seem to be falling off the list again.)
On mer, 2002-05-22 at 01:27, lcrocker(a)nupedia.com wrote:
> >(Random note: Try going to
> > http://www.piclab.com/newwiki/wiki.phtml?title=:Richter_scale
> >You get [[Ichter scale]] instead.)
>
> Fixed, thanks.
>
> > As far as the login: it's still setting a cookie path of /newwiki.
> > (It appears to always set the current directory unless you specify
> > otherwise to setcookie(); a simple fix.)
>
> Fixed. Can I ask what you're using to test cookies? I'm telnetting
> to port 80 and doing things manually which is a pain.
Oh, I'm a lazy one. I just try logging in with Netscape or Mozilla and
look at the resulting cookies file. Good enough for my purposes...
> >A couple other notes on the login screen:
> > * I don't really like the way the "login" is up top and "create
> > new account" down bottom. (I'm the one who made it do that, so
> > blame me... I split them up because it was difficult to figure out
> > how to make them work when they were merged together...
>
> I didn't much like it either, I just quickly copied the old one. It's
> better now, I think. Perhaps some text could be added as well.
Ahh, I like the new one! Compact, yet clear in function.
A couple further thoughts: I suspect we might want to explicitly mark
the e-mail field for new accounts as "optional" to appease the paranoids
out there.
It looks kind of like "Remember my password across sessions" is grouped
in with the 'create new account' function, but as far as I know it
applies both for new accounts and later logins. Should it be separated
by a blank line? Eh.
> > * I'd love it if, after logging in, I got sent back to where I
> > came from!
>
> Great idea! Done.
Woohoo! Thanks.
-- brion vibber (brion @ pobox.com)
On Tue, 21 May 2002 lcrocker(a)nupedia.com wrote:
> (Brion wrote:)
> > I've just submitted changes to special_userlog(in|out).php
> > which should fix the infamous cookie path problem (login
> > cookie sets path of /wiki/ and thus you aren't logged in when
> > you look at / or /wiki.phtml -- yecch!)
>
> This is installed at http://www.piclab.com/wiki/wiki.phtml now,
> so you can test it.
Seems okay so far... cookie path is /, so in theory it should work.
> While the problem is fresh in your mind, it
> would be helpful if you could test /newwiki as well, since one
> of few things I didn't borrow any code at all for is the user
> login system--it's all new, and I think works the way I would
> expect, but it would be nice to have some other opinions on that.
(Random note: Try going to
http://www.piclab.com/newwiki/wiki.phtml?title=:Richter_scale
You get [[Ichter scale]] instead.)
As far as the login: it's still setting a cookie path of /newwiki. (It
appears to always set the current directory unless you specify otherwise
to setcookie(); a simple fix.)
A couple other notes on the login screen:
* Eliminating the separate login step after creating a new account is a
good thing; it saves confusion (and precious mouse clicks). Kudos!
* I don't really like the way the "login" is up top and "create new
account" down bottom. (I'm the one who made it do that, so blame me... I
split them up because it was difficult to figure out how to make them work
when they were merged together -- if you filled out both password fields
it would attempt to create a new account and would NOT log you in to an
existing one. But it's still ugly.) Perhaps we could put them
side-by-side, or just make "create new account" a separate screen which
you can click to from the login form (or from a failed login attempt). In
any case, that's mainly a cosmetic issue.
* I'd love it if, after logging in, I got sent back to where I came from!
If one is logging in in order to edit/deal with watchlist/whatever,
perhaps one is already at a particular page one wants to manipulate, and
doesn't wish to go find it again or back-back-back-reload or use-other-window-
switch-back-reload. (Same would be nice for the user preferences.) What
think you?
* Uhhh, I put another asterisk in here but I don't remember what for. I do
hope it wasn't important.
-- brion vibber (brion @ pobox.com)
I've just submitted changes to special_userlog(in|out).php which should
fix the infamous cookie path problem (login cookie sets path of /wiki/ and
thus you aren't logged in when you look at / or /wiki.phtml -- yecch!)
People will have to re-login to make it take effect once installed...
-- brion vibber (brion @ pobox.com)
http://www.3apes.com/
This is a strictly COMMERCIAL idea of mine. I am pretty sure that the
data would be released under a free license, maybe the GNU FDL, but
more likely something a lot simpler, sort of a Berkeley-style license,
without all the complicated talk about "cover pages" and so forth.
If you don't feel like contributing to such a commercial idea, I
totally understand.
I'd just like to have people play with it and see if it is as fun for you
as it has been for me.
Basically, it is a wiki-style search engine. There's a javascript
"magic button" you can download. This enables you to quickly add neat
sites to the database, and they show up on Recent Changes.
The software is totally homegrown perl of my own making. It's pretty
awful. I'm planning a total rewrite sometime soon.
--Jimbo
Earlier I announced the availability of a new codebase and a testing
server to the wikitech list, but I see no reason not to involve the
larger list as well.
See http://wikipedia.sourceforge.net for information on the wiki
software.
I have both codebases set upon my server (the old one is at
http://www.piclab.com/wiki/wiki.phtml , and the new one is at
http://www.piclab.com/newwiki/wiki.phtml ), and both have the
newest 5/20 dump of the database (though the new one doesn't
have all the article histories).
Anyone who wants to work on the code can use my server for
testing. In particular, I'd like to solicit translators to
create new languages for the new codebase, which has a much
better facility for handling them (and doesn't require any
coding skill).
Finally, someone a while back posted a wikipedia design that
didn't use HTML tables for layout and that looked very clean.
I could probably find that in the archives, but if someone
could point me to that I'd appreciate it. The new skin system
should make it easier to implement that cleanly.
0