I apologize. Clearly, I've offended you. That was not my intention. Your rebuke could be used to shut down many suggestions. If you were working with TPF (in some technical manner) it could be taken seriously. I tried to have you confirm some authority; you said you'd be guessing. I only meant to reply: it doesn't help the conversation to make guesses and discuss them as facts... politely, let's not get outside of our purview. Again, I'm sorry to have provoked your outburst.
This will create a heavy load on the server. I disagree.
Out of the box, SMF is coded with the potential to notify every user immediately of every post. This is evident in the profile settings (Profile>Modify Profile>Notifications), and in the source (Sources/Notify.php:85,159 & Sources/Post.php:2460). This scenario is, of course, an edge case, but would not be exceeded by implementing this suggestion. The point has already been made that it could reduce the amount of actual notifications by increasing their specificity.
Yes, but this will send an email everytime someone replies to the thread, which won't necessarily relate to what you've subscribed for. Whereas getting notified everytime you get quoted, will directly concern what you said, it's much more accurate in my opinion.
My only concern is that I don't think any of us need another website bombarding us with notifications, so I would just want the notifications to be as specific to the user as possible... if that makes sense.
Maybe you're thinking the suggestion is to parse every post for the ~2650 member names in PHP with regex... so yes, poor architecture like that could cause
some load. SMF is not a modern web application. Ignoring the if(!defined('SMF')) and global variable blasphemy, that it sends email notifications without a queue is crazy. As is, the code will choke at scale... but < 500 posts/day is within the performance of the infrastructure.
I don't think the people in charge would add to the codebase in SMF's antiquated style... but that's my opinion, not a fact.
