Watch page WAS Re: [pmwiki-users] Mail Post Manual Trigger

Joachim Durchholz jo at durchholz.org
Wed May 4 10:52:36 CDT 2005


Radu wrote:
> Personally, I'd put the discussion and other sections on a separate page 
> and leave in the PITS entry only the problem, which is to have a way to 
> easily keep track of changes of interest in a wiki.

Mailing change notifications *is* a way of tracking changes of 
interesting pages.

> BTW, when efficiency detracts from usability (e.g. because pages render 
> or save too slowly), efficiency DOES need to be considered. Otherwise we 
> wind up with non-scalable code that's a waste of time to write and 
> maintain. Of course, that's my opinion only.

That's correct. I just thinks got carried away too quickly.

I'd have liked to see a discussion about what's the best user interface 
for monitoring changes. Some people may prefer mails, some people may 
prefer a changelist that they check once a day - I don't know, but the 
issue wasn't even mentioned.

Instead, the page entered into a lengthy discussion about efficiency and 
structural elegance - important points, sure, but it was all too much 
occupied with technical details when it wasn't even clear what the thing 
should do in the first place!

> My point in that pits entry was that emailing the changes gets messy in 
> multiple ways. Recently I was thinking that if emailing needs to be 
> involved, then only a summary of changes per day might be sent out (some 
> sort of summary, but way smaller than a mailinglist digest), containing 
> only links to pages which have changed (or a link to the watch page of 
> the author), and only sent to authors who are interested on the specific 
> modifications.

Yes, that's exactly what I had in mind.

> Since the script should be scalable we could implement a script that 
> pmwiki would run once a day on the first 'read' call of the day (if 
> access to the site crontab is not available). That script would compare 
> yesterday's list of all pages in the site and their modification 
> timestamps with the current timestamps, while caching current 
> timestamps,

Sounds good.

 > and use a list of
> 
> group.page1:user1:email1,user2:email2,user3:email3
> 
> or some such (details of format TBD), to determine who gets an email
> and/or which watchlists need to change. Then it would write the new
> list of pages and modification timestamps. To simplify data entry,
> the email could be stored in a cookie at the client side.

Now again this is getting far too technical for my taste (YMMV).
I still don't know what PmWiki should do; I'm not very concerned with 
how to best implement that. It could be a list like the one that you 
propose, or the "I'm interested" information could be attached to pages 
and the central list would just be a list of pending notifications.

See, programs can do anything you want. Really anything. If the 
programmers moan that you wishes collide with the internal elegance of 
their design, they either have to bite the bullet and write something 
clunky, or they have to adapt the program's structure to match your 
design, or they have to propose alternatives that still achieve what you 
want but work slightly differently (Pm is particularly good at the 
latter, which is a Good Thing since it also keeps PmWiki small and hence 
reliable, because more lines of code means more bugs).

My suggestion is: unless you already know *exactly* what's going on 
inside PmWiki, leave the implementation techniques to somebody who does. 
That way, everybody wins: Pm gets feedback for improvements and can 
concentrate on devising an approach that works (instead of having to 
explain in detail why he doesn't want to implement your approach); you 
can concentrate on what you can do best (suggest improvement); and the 
rest of us can participate in the part of the discussion that we all can 
contribute to (the user interface) without having to delve into the 
depths of PmWiki.

> The maintenance of the 
> page:email list would be done with a click-to-toggle-registration 
> mechanism as described on
> http://www.pmwiki.org/wiki/PITS/00358
>  under proposals.

Which one do you mean - there are several "Proposals" sections now :-)

> New pages would be reported in the email only of the day they are 
> created, and they would be added to all watchlists.

Page creating is an interesting point that I haven't have thought of.

I don't think that all page creations should be indiscriminately sent to 
anybody who ever defined a watchlist though. Some ways to filter page 
creation would be very much in order.
Say, I might be interested about page creations only if they are within 
a specific set of groups (I might be disinterested in monitoring pages 
in a SandBox group, for example).
Maybe this could be simplified, like this: If a user places an entire 
group on his watchlist, he also gets notified about all page creations 
and deletions in that group.

Regards,
Jo



More information about the pmwiki-users mailing list