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