[Pmwiki-users] A rough idea--need feedback/input

[niall b durham]

Howdy all,

Happy new year.

Fair warning: this idea is very rough, but I wanted to bring it up
before I forgot it and to see if anyone would find it interesting.
Also, its in a narrative form, and if you know me, I tend to drone
on...  :)

With PmWiki, each page has a "diff" action which brings up recent
changes.  My idea has similar functionality, but a different 
approach.

It would be nice to easily see what has changed on the Wiki page (in
the "browse" presentation) since a particular date.  I know that when
I'm editing in Wiki, I tend to make several "saves" and look at the
output before I'm finished.  So, just because I look at the most
recent change, doesn't mean I see _everything_ that has changed since
the last time I read the document.  In addition, I'm bad at merging
all the various add/deletes in my head.

I would like to be able to browse the different pages (action=browse) 
and quickly see what has been changed in the context of the entire 
document.

So, there I was reading the _HTML_&_XTHML_The_Definitive_Guide_ book 
from O'Reilly when I came across <ins> and <del> tags (previously, my 
HTML knowledge peaked before the unreleased v3.2 :).  That got me 
thinking.  Wouldn't it be cool if PmWiki would use the information 
in the diff's and mark all the inserted text added after $date with 
<ins ...> </ins> and all the text deleted after $date with 
<del ...> </del>?  I guess there may be loopholes in the 
implementation if you have two diffs since $date that step on each 
other.  I haven't put too much thought towards that.

I figure it should be optional and as simple to operate as possible...
Configurable too, ideally.

I was thinking that--if desired--the user could set a cookie on their
browser which would, record a group name and a timestamp.  From then 
on, every page viewed from that group which had modifications *after* 
that date would have the aformentioned markup applied to the diffs when 
"browsed".  Additionally, extra configuration information could be put 
into the cookie which could influence the style sheet that PmWiki 
generates when it the page is seen (best idea I've had so far is to 
allow the user to configure the colors of text between the <ins> and 
<del> tags). 

We could add action(s) to PmWiki which would allow the user to do a 
few things:

 * Mark a group with the current "time".  E.g.: Say I've read all
   the pages I want to in a particular group--I change the date of my 
   timestamp to $now.

 * Edit the cookie values for insert/delete colors.  Can't think of 
   any other options though.

 * Remove the cookie (so I can go back to browsing like a normal user).

I can't think of a way to make it completely automatic (as far as _not_ 
having to manually mark the timestamp for a group) without having to 
store more information server-side[1].  That would require having to 
track unique users.  While I can see some utility in that, it makes 
things far more complicated and would ruin the sweet simplicity of the 
800-odd line PHP script. :)

If this sounds good, I am willing to donate some time coding if Pm's
time availablity is an issue.

Later,

Niall

----
[1] Reading my ancient _Webmaster_in_A_Nutshell_ book, the spec. says 
    cookies are limited to 4KB or less.  This, in most cases, would
    preclude setting individual timestamps for unique pages without
    coming up with some sort of mapping scheme for each page to limit 
    the amount of space used in the cookie.  Even then, I think it
    would require a lot of compression of the information to be
    workable.  Hmm, some sort of gzip hacking? :)

    Unique groups are fewer but still may provide a useful granularity.

-- 
nbd3355 at sci.tamucc.edu
http://www.cbi.tamucc.edu/~durham/