Menu
▾
▴
phpwiki-talk
|
From: Joe E. <jo...@or...> - 2001-11-20 18:17:27
|
RFC: EmailNotification Syntax and Features
This is an email notification scheme I designed to cover my needs in my own
projects. It may be that it is not appropriate to most people's uses or
tastes. I'm posting the description here to gauge support and to solicit
improvements from people who require slightly different functionality.
Implementation details and questions are covered in another RFC called
"EmailNotification Coding Strategy".
SUMMARY
- PlainEnglish email list syntax
- notification about badge status as well as page changes
- optional anti-spam measures
- phpwiki/admin/notify.php can be run as a cron job to send emails
- hopefully implemented & tested by Dec 1st.
THE SYNTAX
The following wiki code:
NotifyAboutChanges:
* JoeEdelman
* TheHumanResourcesDepartment
* ji...@mi...
should do what you expect iff the page "TheHumanResourcesDepartment"
contains somewhere:
GroupConsistsOf:
* AlexHamilton
* TomJefferson
* ge...@ho...
and the "JoeEdelman", "AlexHamilton", and "TomJefferson" pages have an
'email' component in their page metadata. Nevermind, for now, how it got
there.
These keywords-- "NotifyAboutChanges" and "GroupConsistsOf"-- must occur by
themselves in a paragraph, followed by a colon, and refer only to the
unnumbered list immediately following them. You can, however, stack them.
For instance:
NotifyAboutChanges:
* ArnoldAwl
* BurtBly
* CarlCrow
This is ordinary wiki text.
NotifyAboutChanges:
* DaveDrip
* EddyEck
will email out to all five people when the page is changed.
MORE NEW SYNTAX
1.
That covers changes to a page, but I also need to be able to notify when a
page has a new Category or Badge-- for instance when someone adds "FixMe" or
"NeedsFinancialAssessment" to a page. So we have:
NotifyAboutLinks:
* TheFinanceDepartmentDweebs
2.
And in certain cases I want to send notifications whenever a page has had a
certain Category or Badge for an amount of time-- for instance when "FixMe"
has been on a page for a week and no one has fixed it. On the "FixMe" page:
NotifyAboutLinks (older than 1 week):
* JoeTheFixMeGuy
NotifyAboutLinks (older than 1 month):
* JoesBossJim
|
|
From: Adam S. <ad...@pe...> - 2001-11-20 18:55:23
|
> RFC: EmailNotification Syntax and Features this is great, thanks for publishing this. > NotifyAboutChanges: > > * JoeEdelman > * TheHumanResourcesDepartment > * ji...@mi... i would vote to remove the email option, it makes it too easy for anyone to sign up anyone to get spammed on change notification. having all notifications routed to a wiki page (and thus to an email) also provides a single point of maintenance for end users (need to change your email you just have to do it in one place). if you remove the email meta-data (or maybe change it to a keyword like "disabled") it would also provide an easy way to temporarily unsubscribe. having a wiki page in order to get email notifications doesn't seem too onerous. some form of ack on the addition of an email to a page would be useful to avoid people signing other people up (you add email meta data and then to have it activated you have to respond to an email or something similar). > should do what you expect if the page "TheHumanResourcesDepartment" > contains somewhere: > > GroupConsistsOf: > > * AlexHamilton > * TomJefferson > * ge...@ho... it would be nice if the notion of groups could be generalized so it could be leveraged for authentication purposes. i can't comment if this meets that criteria or not. adam. |
|
From: Steve W. <sw...@pa...> - 2001-11-20 20:56:32
|
On Tue, 20 Nov 2001, Adam Shand wrote:
>
> > RFC: EmailNotification Syntax and Features
>
> this is great, thanks for publishing this.
Yes, most excellent!
>
> > NotifyAboutChanges:
> >
> > * JoeEdelman
> > * TheHumanResourcesDepartment
> > * ji...@mi...
>
> i would vote to remove the email option, it makes it too easy for anyone
> to sign up anyone to get spammed on change notification. having all
> notifications routed to a wiki page (and thus to an email) also provides a
> single point of maintenance for end users (need to change your email you
> just have to do it in one place). if you remove the email meta-data (or
> maybe change it to a keyword like "disabled") it would also provide an
> easy way to temporarily unsubscribe.
Right.. we should bear in mind that people will want to set up a public
Wiki and only registered users can receive email notification.
Also... would it be possible to code for this scenario:
PamOne adds her name to NotifyAboutChanges.
Email is sent to PamOne to confirm.
If she confirms, OK; if not, no further mail is sent for that page, and
possibly her name is removed from the page's list.
Also, users would need a form page telling them what they are subscribed
to and let them unsubscribe from any page (or all of them).
What I find enlightening about Joe's approach is sticking with Wiki markup
to do the job, in plain English (or pick your native language ;-) It's
incredibly simple and Wiki-like.
Also I think we may need (in the future) unbuffered output from the Wiki
when pages are saved... giving the user feedback as the engine does its
thing. I did this for the editing tools at the New York Times when I
wanted to get a lot of cruft removed from the system, but couldn't get
approval; by letting the editors see what the tool was doing, they were
able to complain it was doing things that weren't necessary and I got the
approval I needed.
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
|
|
From: Joe E. <jo...@or...> - 2001-11-21 16:25:48
|
"Steve Wainstead" <sw...@pa...> wrote:
> would it be possible to code for this scenario:
>
> PamOne adds her name to NotifyAboutChanges.
> Email is sent to PamOne to confirm.
> If she confirms, OK; if not, no further mail is sent for that page, and
> possibly her name is removed from the page's list.
Yes. I'll implement this. I want this functionality too. But this will be
in my second revision, probably during January.
> Also, users would need a form page telling them what they are subscribed
> to and let them unsubscribe from any page (or all of them).
Good idea. FullTextSearch might work until I can rig a more user-friendly
plugin version.
> What I find enlightening about Joe's approach is sticking with Wiki markup
> to do the job, in plain English (or pick your native language ;-) It's
> incredibly simple and Wiki-like.
Yeah, I tried to refactor myself after you folks schooled me on WikiBadges
and WikiNature. StructuredDataNoMore!
Thanks everyone for your positive feedback. Feel free to continue to
suggest changes and ideas as they come to you. More to come.
Joe
|
|
From: Joe E. <jo...@or...> - 2001-11-21 16:25:55
|
"Adam Shand" <ad...@pe...> wrote: > i would vote to remove the email option, it makes it too easy for anyone > to sign up anyone to get spammed on change notification. How about this: For release 1 (november) bare emails are possible but by default turned off; For release 2 (january) I'll support some kind of email confirmation scheme. > having all > notifications routed to a wiki page (and thus to an email) also provides a > single point of maintenance for end users Right, the wiki page approach is clearly the better way to add yourself to a list, but I expect that a lot of my users will start as lurkers over email, so I want to make lurking as easy as possible: just an edit away. They can always fix it later, when they become contributing members with their own pages. Certainly it should be off by default, though: I don't want these wikis to become known spam relays! > it would be nice if the notion of groups could be generalized so it could > be leveraged for authentication purposes. i can't comment if this meets > that criteria or not. Yes. Neither can I. I promise that there will be an easy-to-use method for accessing all the members of this kind of group, and I promise that whatever auth solution is arrived at, I'll try to make this blend in. |
|
From: Jeff D. <da...@da...> - 2001-11-20 19:44:43
|
On Tue, 20 Nov 2001 13:06:32 -0500 "Joe Edelman" <jo...@or...> wrote: > RFC: EmailNotification Syntax and Features This is great! Here are some of my initial comments. > THE SYNTAX > > The following wiki code: > > NotifyAboutChanges: > > * JoeEdelman > * TheHumanResourcesDepartment > * ji...@mi... I'm just thinking out loud, but what about something like <?plugin NotifyAboutChanges -- JoeEdelman TheHumanResourcesDepartment ?> It's perhaps a little uglier and more complicated for users to suss out. But it makes it more readily apparent that magic is going on. The plugin could be made to display a "Notify me when this page is edited" button, etc... (Right now, I think, the transform code doesn't support multi-line plugin forms, so for now it would all have to be on one line. That will be fixed at some point, though.) > NotifyAboutLinks: > > * TheFinanceDepartmentDweebs <?plugin NotifyAboutChanges linksonly=true -- TheFinanceDepartmentDweebs ?> Arguments which limit the links which are of interest would also be possible. > 2. > > And in certain cases I want to send notifications whenever a page has had a > certain Category or Badge for an amount of time-- for instance when "FixMe" > has been on a page for a week and no one has fixed it. On the "FixMe" page: > > NotifyAboutLinks (older than 1 week): > > * JoeTheFixMeGuy <?plugin NotifyAboutStaleLinks timeout="1 week" -- JoeTheFixMeGuy ?> I guess I hate to introduce still more new syntax. (Though I admit I'm not really one to cast stones, being that MagicPhpWikiURLs and the plugin syntax are both my fault.) I'm certainly not completely happy with the plugin syntax at this point, and you should have no fear of proposing changes to it... More in the reply to your next post... Jeff |
|
From: Joe E. <jo...@or...> - 2001-11-21 22:53:28
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X