[Pmwiki-users] A rough idea--need feedback/input
niall b durham
nbd3355 at sci.tamucc.edu
Fri Jan 10 14:35:35 CST 2003
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/
More information about the pmwiki-users
mailing list