Re: [Phpwiki-talk] RFC: EmailNotification Syntax and Link.ctime

[Joe E. <jo...@or...>]

TALKING SYNTAX

Jeff, although it's great for content expansions, I don't think your
<?plugin?> syntax is a good candidate for EmailNotification for the
following reasons:

1) While it would suffice for NotifyAboutChanges, the NotifyAboutLinks
plugin has to run some code on every new link, even those made while editing
pages that never mention NotifyAboutLinks-- we still need the event stuff.

2) I don't see the "NotifyAboutChanges:\n\n{list}\n\n" construct as defining
new syntax so much as offering a new convention.  It is outside the reach of
the transform/link code and renders the same as anything else.  Event-based
plugins that hook 'onMajorRevision' can presumably use their handlers to
look for anything, even a person's name or a certain pattern of dialogue.
This one happens to look for the words "NotifyAboutChanges" followed by a
list.

3) The <?plugin?> approach would presumably hide the data inside the plugin
from the user during an ordinary render.  From the user's perspective, I bet
this will feel more like voodoo than the PlainEnglish alternative.  One of
Wiki's strengths is that, when you hit EDIT, you get something that looks a
lot like BROWSE.  I think we should act to minimize those surprises and keep
edit looking very much like browse.

4) Tooling around wikis in the last month or so I've been really impressed
by the plaintext aesthetic.  With my newfound design sensibilities, a
"notify me when this page is edited" button in the middle of things seems
like an unnecessary and disruptive doodad in an otherwise tranquil sea of
hypertext.  I'd rather they just edit and add their name to the list.


AND NOW BACK TO LINK.CTIME

Alarms can definitely replace page_expire.  Forget you ever heard the words
page_expire.  I have found the new religion of WikiTimerManager!

BUT...

I'm not sure whether the same thing can work on a link level.  You see, I
don't want to send an email per stale link, I want to send an email per
"NotifyAboutLinks (older than):" block.  Each of these emails will inform
about all of the links that are unnotified and older than the block's
threshold.  The only way I can think to do this with alarms & callbacks at
the link level would be to have the callback function add the links into a
big data structure in memory which is kept sorted by (page,
older_than_block) and then step through this sorted structure after
$am->run().  But this uses a lot of memory for large updates.

An alternative would be to build some way to group the alarms based on their
metadata and $am->run() the groups, but that seems like an abuse of the
WikiTimerManager concept.

So it looks like we're back to link.ctime, unless you see something that I
don't see.

Regards,

 Joe