Wedge

Just wanted to give this topic a bump, I'm still working on it (whenever I can, hardly getting time these days due to exams, then SMF4Mobile and all).  I wanted some opinions on what you guys think about the core plugin and all.

Some terminology, so that people don't get confused later.
Notifier: This is the object that actually issues notifications. For example, TopicReply is a notifier that issues notifications whenever a replied is posted to a person's topic.
Notification: Pretty obvious, individual messages sent to people to tell what's going on
NotifSubscriber: I probably need a better name for this, short for Notification Subscriber, this is another object which handles individual types of subscription. For example, there can be a subscriber for Board which handles sending out subscription notifications for any new topic in a specific board.

Basically, currently the core of notifications is divided into two. First is handling the notifications themselves, it allows plugins to have notifier and issue notifications to user. It also handles disabling of specific notifiers, individual preferences (if any) etc. in a single profile page. The second part handles subscriptions, basically anything that the user isn't directly linked to but wants to get an update of (same as current Wedge subscriptions). Subscription part is build on top of the notification core and is optional, it obviously aims at replacing the current mess of a subscription Wedge (and, by extension, SMF) has with a simpler UI and more modularity. My aim is to make the subscription option themselves simpler, an user can subscribe to a specific topic and see his or her subscription info from their profile, and remove them if they want. The advance notifying stuff (stuff like e-mail once every week etc.) gets moved to the notifications core. This way, other notifier can also, by default, take advantage of having some nice e-mailing options.

Currently subscriptions are divided into two parts, so one needs to code these two in order to add a new subscriptions . First is their subscriber, and second is their notifier. Subscriber handles all the subscription part of the equation, i.e. validating of topic (for example) they're trying to subscribe to  and issuing subscription notifications themselves whenever required (like when a new topic is posted). Notifier handles the notifications of the subscription, i.e. what to actually say when a notification is issued, what to do when there are multiple unread notifications of the same type, and notifier specific preferences (this is valid to other types of notifier as well and not only subscriptions).

To give an elaborate example for a subscription, if someone needs to create a plugin where anyone is notified when a specific user is quoted in a post (probably a stupid idea, but it gets the point across). A member will subscribe to another member to receive the notifications. One will firstly code the notifier itself. The notifier will have a few functions, firstly to return what the text should say for a specific notification, the e-mail text etc. and what to do if there are multiple unread notifications of the same type (so that it can say "admin has been quoted in "Re: Test" and 4 other messages"). Then comes the subscriber, which will handle identifying the subscriber itself (for internal purposes) and validating the member when someone is trying to subscribe to them, i.e. whether the member is valid and can be subscribed too or not. The plugin then will hook to post_form (or whichever hook is called after a post has been created),  and check if a member has been quoted, and if there has been a member who's been quoted, it will issue all the subscription notifications. The issuing part is mostly simple, you just need to call a function, say which subscriber you are (memberquote in this case) and for which object are notifications being issued (the member who has been quoted in this case) and pass any arbitrary data (post subject, etc.) that can be useful when displaying notification. The internal function (part of the core plugin, already coded, no need to code anything more here) will handle actually sending out the notifications to whoever has subscribed to that specific member. The plugin will also hook to appropriate places to add the button/UI for providing a link to actually subscribe to the place (the subscription action is handled by the core, but the UI is provided by the plugin which is adding a subscriber since it can be at any number of places).

I already have a couple of examples for simple notifiers, see them in my GH repository.

This can be a fairly bit complex to explain without code examples, but any feedback is appreciated. Is it too complex to extend? Any ideas which can probably make it simpler? Any examples of other systems which already do this and work well? Thanks :)

Okay, this is the first working example of a subscription plugin: https://github.com/Dragooon/WeNotif-Subs-Topics

It allows one to subscribe to topics, coded in about 30 minutes at 4:30 AM so it's still very rough and a bunch of things are still left to do, but it seems to be working fairly fine. You can see how a subscriber is implemented, this should give a nice example of one.