I thought I'd announce this before I go, anyway, I've been working on a full fledged notifications of Wedge which is meant to serve as a replacement for all the existing notification with a fully pluggable notifications system.

The system plugin by default provides no notifications, but various plugin that will come with it that provides notifications for various actions. Currently implemented features:

- Allow plugins to easily issue notifications without much hassle- Provide the user an easy interface to view those and mark as read, currently it's displaying 5 latest unread notifications on the sidebar with an option to view all notifications. The notifications are marked as read automatically as soon as they're clicked.- Allow individual notifiers to be disabled per user, i.e. an user can choose to not receive notification for topic replies etc.- Allow notifiers to send e-mails for notifications, which can be disabled on a per notifier basis by the user- Allow e-mails to be received instantly, daily or weekly (not implemented yet)

The aim of the system is to provide an easy API for plugins to notify users without having to re-implement all the features again. Plus it provides a centralized system for receiving/viewing notifications.

Notification extensionsThese plugins use the notifications core to issue notifications in various events, the notifications core itself is useless. These can be used as a sample for notification extensions

ID: Dragooon:WeNotif-TopicReply

Notifies the author of a reply to their topic

ID: Dragooon:WeNotif-Quote

Notifies the author if someone has quoted their post

I'll be working on replacing the existing notifications next, by providing plugins that mimic the funcionality but work full and well with the notification system.

“I will stand on my ground as an atheist until your god shows up...If my irreligious bothers you much, and if you think everything I do is heresy to your god I don't care. Heresy is for those who believe, I don't. So, it isn't heresy at all!

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 onNotifSubscriber: 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 :)

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.

Yup :), it's working out okay. The core plugins still need a lot of work (I need to work on it during daytime more, the code needs tidying up), but the basic structure should remain same. The topics extension is more or less complete, I don't think it should need anything more except a couple of things that are todo, what do you think of the code (simplicity wise) itself? It's a complete implementation for topic subscription, any other plugin will have to do similar things to add their own notification subscriptions.

Ahah, this is the public topic....reminder: implement the option to automatically subscribe to your threads.

Also, for the others:

Quote

I know the plugin uses the sidebar but I'm not entirely convinced that's workable at present - I would never, ever see my own notifications on the desktop because I have my window sized at around 1000px, gives me enough room for dual pane work, but has the side effect that the sidebar is pushed to the bottom. Makes me wonder about having something up in the header area for the user.

Okay, this is one of the last issues I'd like to work out before giving it a go for installation on a live site for testing, any ideas where this can go? I'm thinking either:1) Make a big number counter next to the site's title2) Make a menu entry and display the counter there, which expands to show quick unread notification with the option to show all.3) Make some sort of floating box?