Wedge

Oh classes should be added for contexts, they can provide good theming opportunities if nothing else.

True that.

While we're on topic, can I ask a core feature request to indicate whether the poster is the OP? :P...

It isn't just the post template I'm curious about, just any template in general.

Can something like hook tags be added to the templates which are replaced by HTML added by hooks during the buffer rewriting, where you also process the <we:cat> etc[1]. Add a bit more pre-defined templates (similar to <we:cat> etc) and theming cannot be a complete mess.

EDIT: The above idea is potentially stupid for contextes where data processed in the template is required....

Second EDIT: This above idea is actually pretty stupid in almost all the cases, this is almost same as adding a call_hook to templates and that can actually pass data.

1.	Not entirely sure, but I believe it's done around buffer rewriting part of the process?

I'm fairly sure he meant when the user doesn't know how to actually type the special character (via keyboard or through Alt codes) and would, instead, generally type the character code.

No, that's not what I meant. I realised that this is already implemented in Wedge, but what I was asking was what happens when there are a lot of smileys? A lot of forums have huge smiley packs and many of them are animated, that makes for a few MBs of smileys in a CSS file which will be loaded at once, it'll probably cross a few browser's cache limits as well (especially on mobile, iOS doesn't even cache permanently and ANdroid can have a few MBs of cache depending upon the device but it can still be an ugly ride).

Okay, reading the source it seems it won't embed smileys beyond 4KB, that'll probably help quite a bit. But perhaps it should limit the CSS file beyond a limit?

Can CSS handle animated gifs?

This is sweet :D. What does it require post fields for?

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