phpwiki-talk

Re: [Phpwiki-talk] mysql, pgsql test out

[Jeff D. <da...@da...>]

On Sep 19, 2001, Steve Wainstead said:
> 
> I had to make the same fix to DB.php that Jeff did on the
> alpha site.

I just checked in some fixes which work around the bugs in DB.php.
(So things should work without patching the stock DB.php.)
I've now tested (briefly) the MySQL backend with the PEAR code
from PHP releases 4.04pl1, 4.05, and 4.06.  (The 4.06 code is the
only one with the bug.)  With the fixes I just checked in, they
all seem to work fine.

I've also fixed things so that (as long as you have the PEAR code
installed on your system in some standard-ish place) you shouldn't have
to mess with making sure the PEAR code is in the include_path.

Jeff

[Phpwiki-talk] mysql, pgsql test out

[Steve W. <sw...@pa...>]

I spent the afternoon figuring out mysql security, and finally got it in a
usable state; I had to make the same fix to DB.php that Jeff did on the
alpha site.

With that in place I was able to run the current CVS snapshot on mysql and
pgsql.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Diff feature request...

[Jeff D. <da...@da...>]

On Sep 18, 2001, Adam Shand said:
> 
> that would actually be kind of a cool feature.  in comparison to what the
> wiki already has to do to serve a page how noticeable is the overhead from
> using sessions?
> 
> if it's minimal what is the downside to using sessions?
> 

I just thought I'd add:

Sessions are already being used in the latest hacks.  At this point
as a kluge to get around funnyness in the current user login code,
all of which is going to be replaced sometime fairly soon, I hope.
(Mozilla won't accept cookies as part of a "401 unauthorized"
response.)

Re: [Phpwiki-talk] setting up the alpha site

[Jeff D. <da...@da...>]

On Sep 18, 2001, Steve Wainstead said:
> 
> Unfortunately this generates a lot of errors:
> 
> http://phpwiki.sf.net/alpha/
> 

I think it's a bug in whatever version of PEAR DB they have on SF.

It doesn't recognize "LOCK" as one of the SQL command which doesn't
return any data, and so throws an error when it doesn't.

I've kludged it up for now, by copying a patched version of DB.php
into htdocs/alpha.  (The only difference attached at the end of this
note.)

It's interesting to note that the version of DB.php on SF
in significantly more recent than the one I've been using,
yet has this show-stopping bug.  I hope that using the PEAR
stuff isn't going to cause too many headaches in this regard.

I'll look into reporting the error to the PEAR guys...

Jeff

--- DB.php.orig	Tue Sep 18 17:20:06 2001
+++ DB.php	Tue Sep 18 17:17:24 2001
@@ -297,7 +297,7 @@
      */
     function isManip($query)
     {
-        if (preg_match('/^\s*"?(INSERT|UPDATE|DELETE|REPLACE|CREATE|DRO
P|ALTER|GRANT|REVOKE)\s+/i', $query)) {
+        if (preg_match('/^\s*"?(INSERT|UPDATE|DELETE|REPLACE|CREATE|DRO
P|ALTER|GRANT|REVOKE|LOCK|UNLOCK)\s+/i', $query)) {
             return true;
         }
         return false;
{

Re: [Phpwiki-talk] Diff feature request...

[Adam S. <ad...@pe...>]

> I do support something like "who's online" and "who's looking at
> that". timeout is usually 30 minutes. every hit has to update the
> session state (either memory, file or database), propagating the
> session id via url params or cookies.  and every hit has to purge old
> sessions. no big deal.  this way I propagate the user_name and more
> without cookies.

that would actually be kind of a cool feature.  in comparison to what the
wiki already has to do to serve a page how noticeable is the overhead from
using sessions?

if it's minimal what is the downside to using sessions?

adam.

Re: [Phpwiki-talk] Diff feature request...

[Reini U. <ru...@x-...>]

Steve Wainstead schrieb:
> On Tue, 18 Sep 2001, Adam Shand wrote:
> > > I've noticed that the page-edit lock frustrates users, when they do a
> > > long edit and it fails.
> >
> > i've never understood this.  why don't wiki's tell you when you *try* to
> > edit a page that someone else is already editing it?  that seems more
> > sensible to me then after a page has been being edited for X amount of
> > time user should have the option of waiting or breaking the lock.
> 
> HTTP is a stateless protocol. That is, you make a connection, get the
> page, and disconnect. Compare this to a telnet session, which is stateful.

if we use php4 and sessions or the session support from the phplib we can 
add state. 

I do support something like "who's online" and "who's looking at that".
timeout is usually 30 minutes.
every hit has to update the session state (either memory, file or database), 
propagating the session id via url params or cookies. 
and every hit has to purge old sessions. no big deal. 
this way I propagate the user_name and more without cookies.

anyway, just to solve the problem to know if someone else is editing 
the same page, adding session support for phpwiki is probably overkill.

we could get rid of cookies. cookies could be made optional. 
if none are supported, the session is transported via url or hidden inputs 
in post forms.

> If you think the current situation is frustrating, the previous situation
> was far far worse: you'd spend a long time making changes to a page, save
> those changes, and then come back an hour later and find someone
> accidentally saved *their* copy over yours, and all your changes are not
> only lost, they are irrecoverable! This is the Lost Update Problem.
> 
> Now, at least you can pull your copy from the archive. The irritating
> page-edit lock, as it exists now, at least prevents you from losing
> everything.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] setting up the alpha site

[Steve W. <sw...@pa...>]

I've almost got the alpha site up on SF -- almost -- but DB.php is not in
the include path. Anybody know where they hide it? It's possible they
don't support it yet.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Diff feature request...

[Steve W. <sw...@pa...>]

On Tue, 18 Sep 2001, Adam Shand wrote:

>
> > I've noticed that the page-edit lock frustrates users, when they do a
> > long edit and it fails.
>
> i've never understood this.  why don't wiki's tell you when you *try* to
> edit a page that someone else is already editing it?  that seems more
> sensible to me then after a page has been being edited for X amount of
> time user should have the option of waiting or breaking the lock.

HTTP is a stateless protocol. That is, you make a connection, get the
page, and disconnect. Compare this to a telnet session, which is stateful.

If Keesha fetches HomePage and starts to edit it, she gets the current
version in the Edit page. Maybe she edits it, maybe not. Maybe she goes
home for the day.

Elmer then wants to edit HomePage. But the Wiki tells him someone else is
editing it so he waits, and waits and waits.

Meanwhile Keesha's computer is crashed overnight by the new "nimbda" worm.
She never gets to save her changes. In fact, now there is a lock on the
file and noone can change it.

This is one of many scenarios possible because HTTP is stateless. The
server has no way of knowing when (if ever) Keesha will save her changes.

WebDAV extends the HTTP with new features to handle collaboration like
this. A WikiWikiWeb, however, is just a quick and dirty solution to
collaboration on content. We don't worry (much) about such fundamental
problems.

If you think the current situation is frustrating, the previous situation
was far far worse: you'd spend a long time making changes to a page, save
those changes, and then come back an hour later and find someone
accidentally saved *their* copy over yours, and all your changes are not
only lost, they are irrecoverable! This is the Lost Update Problem.

Now, at least you can pull your copy from the archive. The irritating
page-edit lock, as it exists now, at least prevents you from losing
everything.

~swain


---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Diff feature request...

[Adam S. <ad...@pe...>]

> I've noticed that the page-edit lock frustrates users, when they do a
> long edit and it fails.

i've never understood this.  why don't wiki's tell you when you *try* to
edit a page that someone else is already editing it?  that seems more
sensible to me then after a page has been being edited for X amount of
time user should have the option of waiting or breaking the lock.

adam.

Re: [Phpwiki-talk] Jeff's hacks are in the CVS repository.

[Jeff D. <da...@da...>]

On Sep 18, 2001, Steve Wainstead said:
> On Tue, 18 Sep 2001, Reini Urban wrote:

> > db_upgrade-1.3.sh or db_upgrade-1.3.php anyone?
> 
> I would hope that we can still save the pages from any version of PhpWiki
> as a zip file, and use that to load the new version. In theory it works.
> :-)

Yes, this is what I would suggest.  Currently the file/zip upload seems 
to
broken --- I'm not sure why, I'll work on it right now.  Loading a 
(server-local)
file or zip-archive still works, AFAIK.

Also, if you're loading up a virgin wiki, you can point WIKI_PGSRC
(in index.php) to a zip dump of your previous wiki to initialize the new
db to more-or-less an exact copy of the old one.

Jeff

[Phpwiki-talk] first pass looks great!

[Steve W. <sw...@pa...>]

I have the newest version from CVS running on Red Hat 7.1, PHP 4.0.6,
using gdbm. Looks really great!

Nice work Jeff!

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Jeff's hacks are in the CVS repository.

[Steve W. <sw...@pa...>]

On Tue, 18 Sep 2001, Reini Urban wrote:

> Jeff Dairiki schrieb:
> >       WARNING: all database schemas (currently MySQL, Postgres and DBA
> >       support is working) use completely revised schema, so you must
> >       start this new code with a new blank database...
>
> db_upgrade-1.3.sh or db_upgrade-1.3.php anyone?

I would hope that we can still save the pages from any version of PhpWiki
as a zip file, and use that to load the new version. In theory it works.
:-)

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: [Phpwiki-talk] Jeff's hacks are in the CVS repository.

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
>       WARNING: all database schemas (currently MySQL, Postgres and DBA
>       support is working) use completely revised schema, so you must
>       start this new code with a new blank database...

db_upgrade-1.3.sh or db_upgrade-1.3.php anyone?

In a recent mysql upgrade for another e-commerce project 
I wrote a shell script which ran a mysql query which created a mysql query 
which updated the mysql db.

I'll try to use this trick for PHPWIKI. Simplier than a php script.

p2c_simplify:
#!/bin/sh
TEP_DB=catalog
MYSQL_USER=rurban
MYSQL_PASSWD=
MYSQL_DATA=/var/mysql

# create an update query on the fly.
MYSQL_CMD="mysql -u$MYSQL_USER"
if [ ! -z $MYSQL_PASSWD ]; then MYSQL_CMD="$MYSQL_CMD -p$MYSQL_PASSWD"; fi
TMPFILE=$MYSQL_DATA/tmp.sql

rm $TMPFILE ./tmp.sql
$MYSQL_CMD $TEP_DB <p2c_simplify.sql 
mv $TMPFILE .
$MYSQL_CMD $TEP_DB <tmp.sql

p2c_simplify.sql:
## move essentially unsupported n:m products : categories into 1:n
## remove products_to_categories
## Usage: mysql db <p2c_simplify.sql 

ALTER TABLE products ADD COLUMN categories_id int(5) default '0' not null;
ALTER TABLE products ADD INDEX categories_id (categories_id);

## hacking around stupid mysql limitations:
##UPDATE products AS p LEFT JOIN products_to_categories AS p2c USING
(products_id) SET p.categories_id = p2c.categories_id;

SELECT "UPDATE products SET categories_id=",p2c.categories_id," WHERE
products_id=",p.products_id,";" INTO OUTFILE './tmp.sql' FROM products as p
LEFT JOIN products_to_categories as p2c ON p.products_id = p2c.products_id;

# Got the idea?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Diff feature request...

[Seth C. <se...@eu...>]

So long as we are talking about diffs....

consider this a feature request.
I've noticed that the page-edit lock frustrates users, when they do a long
edit and it fails.
It would be very very nice to have a diff feature there....
Maybe even a merge?
Merging older versions (admin only?) would also be great, as I've noticed
that some people will (due to the above frustration) cut the whole thing,
paste into a new edit window, and blammo, lose of the other edits (it's in
history, but has been effectively lost, until someone rescues it).

P.S. I got the PHPWiki module for PHPNuke.  The author wants me to try it
out, and then if it works, he'll put someone public... but if anyone of you
on the list want to try it (the more testers the better), let me know.

[Phpwiki-talk] Jeff's hacks are in the CVS repository.

[Jeff D. <da...@da...>]

As those of you who are on the phpwiki-checkins mailing list are now
painfully aware, I've just checked my latest hacks into the CVS 
repository
(main branch).  (I tagged the last pre-hack version of the code
with the 'pre_jeffs_hacks2' tag.)

Directions on how to access the CVS repository are available at:
  http://sourceforge.net/cvs/?group_id=6121

If you're going to 'cvs update' your source tree, remember to
use the -d option ('cvs update -d') or you won't pick up the
new subdirectories.


For those of you not on phpwiki-checkins, here's the log message:

  Jeff's hacks II.

  This is a major change, to say the least.  Some highlights:
    o Completely new database API.

      WARNING: all database schemas (currently MySQL, Postgres and DBA
      support is working) use completely revised schema, so you must
      start this new code with a new blank database...
    
    o WikiPlugins
    o New template engine.

  In addition, some more incremental changes:
    o Cascading Style Sheets reworked.
    o Expanded syntax for text search: e.g. "wiki OR wacky AND NOT 
page".
    o PhpWiki should now work with register_globals off. (Security 
issue.)
    o Edit preview button.
    (and probably more, which I'm forgetting about now.)



  Much of this code is still in a state of flux (particularly
  the new template engine code, and to a lesser extent the API
  for the plugins.)
  Feel free to play and hack on this, just be warned that some of it may
  still change quite a bit...

  See pgsrc/ReleaseNotes for a few more notes.

  And feel free to post questions or comments either publicly on
  <php...@li...>, or privately, to
  <da...@da...>.


Jeff

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshacks snapshot. )

[Adam S. <ad...@pe...>]

> (Right now, the only page meta-data being used is 'locked' and
> 'hits'.) This data is not visible (or editable) to the wiki-user
> without providing some explicit mechanism for this.  (I.e. the
> MostPopular plugin displays the value of 'hits'.)  (The DebugInfo
> plugin currently displays all of the page meta-data --- but obviously
> that would be fixed if sensitive information like passwords were
> stored as page meta-data.)

or maybe make debug only available to the listed wiki admins?

also passwords should not be stored in plain text.  what about a worse is
better solution of just storing the crypted password as plainly visible
metadata?

it can be brute forced but it's simple and if people choose good passwords
(ha!) it should be "good enough".

> My thinking is that if everyone is going to have a WikiHomepage, then
> storing their user information as part of the meta-data for their
> homepage is a fine idea.

i really like this idea, it feels like the "wiki way" to me.

> How much user information do we envision storing, anyhow?
>   E-mail address
>   Password
>   Full name, probably

maybe later, groups that you belong to (admin, editor etc)

>   Page change notification prefs: these might be better stored as
>     meta-data attached to the pages for which notification is desired?
>     Or one could also think up other schemes: user gets change
>     notifications for all pages linked from their homepage...

i was just thinking about this.  i think it makes more sense to have it
stored in the page name, other wise every page update means that the
entire user database has to be searched everytime a page is changed to see
who should get emailed.

however this means that unsubing from a wiki could be a pita if you have
10's of pages that you're sub'd to.  some form of search tool or "unsub
all" functionality would be very useful.

> > For now we might just let the username link to a page of the same name,
> > and if they want to be called HomePage, well, what can one do.
>
> But if it really is their homepage, they ought to be allowed to lock
> it...

lets not look at automated ways of stopping this.  hopefully this will be
a small enough problem that the admin can deal with it manually.  most of
the pages which would cause problems if someone chose them for a name
(HomePage, FrontPage, RecentChanges, CategoryCategory etc) should exist by
default in the basic wiki.

> On the subject: I want to add the ability to generate word-level
> diffs, a la emacs' ediff mode.  This would be particularly useful for
> wikis, where a "line" can be a whole paragraph --- if only one word
> has been changed, often it's very hard to spot.  I think this is a
> fairly straightforward enhancement: compute the diff normally (by
> lines), then foreach block of changed lines, split the blocks into
> words and compute a diff by words.

that would be great, can we have side by side diffs as well?

adam.

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshackssnapshot. )

[Adam S. <ad...@pe...>]

> To avoid becoming an instrument of spammage, we probably don't want to
> allow just anyone to sign arbitrary users (or e-mails) up for page
> change notifications.  Or do we?

we want to make sure that the only people who can get wiki changes spam
are people that are participating, unless you want to make people ack
every page addition (which sounds like a hassle to me.

i say make home pages append only.  so people can still leave discussion
and conversation can happen there, but the primary info can't be messed
with.

when people register have them optionally submit their email address, if
they do then send them email, if they ack the message (probably by going
to a url) then put a signed hash of their email address in the wiki.

now when they want to sign up for changes on a page they can add their
HomePage to the Subscribe metadata field of that page.

adam.

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshackssnapshot. )

[Gary B. <ga...@in...>]

On Tue, 18 Sep 2001, Steve Wainstead wrote:

> On Tue, 18 Sep 2001, Jeff Dairiki wrote:
>
> > To avoid becoming an instrument of spammage, we probably don't want to
> > allow just anyone to sign arbitrary users (or e-mails) up for page
> > change
> > notifications.  Or do we?
>
> no, most certainly not. The one patch we got many months ago allowed this;
> one just puts one's email address in the page, I think it was. Not good.
> Fine on an intranet though!

Well, if you allow  all users to read and edit the wiki but allow them to
create an account which will a) log their name on RecentChanges instead of
their IP, and b) allow them to get email notification. When they create
the account, they are sent an email saying "visit this URL to confirm your
email addr", and PhpWiki enables the account fully when the URL is
visited.

Cheers,
Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshackssnapshot. )

[Steve W. <sw...@pa...>]

On Tue, 18 Sep 2001, Jeff Dairiki wrote:

> To avoid becoming an instrument of spammage, we probably don't want to
> allow just anyone to sign arbitrary users (or e-mails) up for page
> change
> notifications.  Or do we?

no, most certainly not. The one patch we got many months ago allowed this;
one just puts one's email address in the page, I think it was. Not good.
Fine on an intranet though!

~swain


---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshacks snapshot. )

[Steve W. <sw...@pa...>]

On Tue, 18 Sep 2001, Jeff Dairiki wrote:

> > In this case it might be better to just go ahead and create a user table,
> > since we will have one anyhow, no matter what. User auth is coming and
> > storing users and pages in the same table will cause problems.
>
> That is the kind of answer I was looking for, but how, exactly, is it
> going to cause problems?

Oh, just that I imagine later on we will want (or admins will want) more
flexible, accessible access to user info. If you want to generate a list
of all users who accessed the wiki in the last ten days, how would you
write a SQL query to do that if all the user info is in page metadata?
Just an example.


> To clarify, again, my proposal:
> In the new API, arbitrary key/value meta-data can be attached to any
> page.
>
> The way you (the PHP programmer) does this is via an interface like:
>    $page = $dbi->getPage('JeffDairiki');
>    $page->set('is_homepage', 1);
>    $page->set('password', 'gobbledygook');
>
>    ....
>    if ($page->get('is_homepage')) {
>        $passwd = $page->get('password');
>        ...
>    }
>

I like this idea... having hashes for whatever one might want is always
useful!


> I'm also, of course, trying to avoid implementing yet another database
> interface (with mechanisms for backing up and restoring, etc...)

quite understandable...


> I suppose my diff code could still use a little cleaning up --- and
> could
> certainly use docs --- but it's basically ready to go.

Cool.


> On the subject: I want to add the ability to generate word-level diffs,
> a la emacs' ediff mode.  This would be particularly useful for wikis,
> where a "line" can be a whole paragraph --- if only one word has been
> changed, often it's very hard to spot.   I think this is a fairly
> straightforward enhancement: compute the diff normally (by lines), then
> foreach block of changed lines, split the blocks into words and compute
> a diff by words.

And I'd still like to redo the diff output to look like sdiff, or what you
get from cvsweb.cgi... very readable...

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshackssnapshot. )

[Jeff D. <da...@da...>]

On Sep 18, 2001, Reini Urban said:
> for page change notifications everybody can just add his email 
> as comment in a special meta tag. very cool!
> no need for a checkbox and database gyrations.

To avoid becoming an instrument of spammage, we probably don't want to
allow just anyone to sign arbitrary users (or e-mails) up for page 
change
notifications.  Or do we?

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshacks snapshot. )

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> On the subject: I want to add the ability to generate word-level diffs,
> a la emacs' ediff mode.  This would be particularly useful for wikis,
> where a "line" can be a whole paragraph --- if only one word has been
> changed, often it's very hard to spot.   I think this is a fairly
> straightforward enhancement: compute the diff normally (by lines), then
> foreach block of changed lines, split the blocks into words and compute
> a diff by words.

Yes, this is by far better. It is even the best diff I know of.
yellow for lines and blue for words.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshackssnapshot. )

[Reini U. <ru...@x-...>]

Adam Shand schrieb:
> > But a user table is still needed for the password, email and
> > page change notifications.
> > I wouldn't store this in the homepage as metadata.
> 
> > Or do you have an idea to protect it for other users?
> >   (not viewable metadata, but editable for the owner...)
> 
> yep, it would be in a comment/metadata field in the page source.  it would
> be viewable when edited but would not display in a browser (or even be in
> the html source).
> 
> at least that was the lines i was thinking down.

Seems to be simple and cool.

for page change notifications everybody can just add his email 
as comment in a special meta tag. very cool!
no need for a checkbox and database gyrations.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshacks snapshot. )

[Jeff D. <da...@da...>]

On Sep 17, 2001, Steve Wainstead said:
> 
> OK... my experience has been, whenever you denormalize the database
> design, you wind up wanting to get at the info that's no longer atomic.

Er...  Could you say that again, in English?

> In this case it might be better to just go ahead and create a user table,
> since we will have one anyhow, no matter what. User auth is coming and
> storing users and pages in the same table will cause problems.

That is the kind of answer I was looking for, but how, exactly, is it
going to cause problems?

To clarify, again, my proposal:
In the new API, arbitrary key/value meta-data can be attached to any 
page.

The way you (the PHP programmer) does this is via an interface like:
   $page = $dbi->getPage('JeffDairiki');
   $page->set('is_homepage', 1);
   $page->set('password', 'gobbledygook');

   ....
   if ($page->get('is_homepage')) {
       $passwd = $page->get('password');
       ...
   }

(Right now, the only page meta-data being used is 'locked' and 'hits'.)
This data is not visible (or editable) to the wiki-user without 
providing
some explicit mechanism for this.  (I.e. the MostPopular plugin displays
the value of 'hits'.)  (The DebugInfo plugin currently displays all of
the page meta-data --- but obviously that would be fixed if sensitive
information like passwords were stored as page meta-data.)

My thinking is that if everyone is going to have a WikiHomepage, then
storing their user information as part of the meta-data for their 
homepage
is a fine idea.

I'm also, of course, trying to avoid implementing yet another database
interface (with mechanisms for backing up and restoring, etc...)

How much user information do we envision storing, anyhow?
  E-mail address
  Password
  Full name, probably

  Page change notification prefs: these might be better stored as
    meta-data attached to the pages for which notification is desired?
    Or one could also think up other schemes: user gets change
    notifications for all pages linked from their homepage...


> For now we might just let the username link to a page of the same name,
> and if they want to be called HomePage, well, what can one do.

But if it really is their homepage, they ought to be allowed to lock 
it...



> I haven't looked... there must be something like this. On a similar note,
> how hard would it be to make the diff engine a module people could reuse?

Easy.  This was my original intent.  I don't know who it was (Arno 
maybe?) who
added the PhpWiki-specific code on the end of my diff source file --- 
actually,
maybe it _was_ me, I can't remember --- in any case, I always
envisioned that nothing but class definitions be in 'libdiff.php' and 
the
PhpWiki invocation of the classes somewhere else.

I suppose my diff code could still use a little cleaning up --- and 
could
certainly use docs --- but it's basically ready to go.

On the subject: I want to add the ability to generate word-level diffs,
a la emacs' ediff mode.  This would be particularly useful for wikis,
where a "line" can be a whole paragraph --- if only one word has been
changed, often it's very hard to spot.   I think this is a fairly
straightforward enhancement: compute the diff normally (by lines), then
foreach block of changed lines, split the blocks into words and compute
a diff by words.

Re: WikiWebLogs and PartialLocks (was Re: [Phpwiki-talk] New jeffshacks snapshot. )

[Adam S. <ad...@pe...>]

>
> But a user table is still needed for the password, email and
> page change notifications.
> I wouldn't store this in the homepage as metadata.

> Or do you have an idea to protect it for other users?
>   (not viewable metadata, but editable for the owner...)

yep, it would be in a comment/metadata field in the page source.  it would
be viewable when edited but would not display in a browser (or even be in
the html source).

at least that was the lines i was thinking down.

adam.