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.