How does SMF know when not to send another notification?

[Suki]

Surely you realize you now are performing multiple DB calls everytime an user hits the "send" button right?

You basically traded sending mails for something much worst.

[Biology Forums]

Keeping in mind the cost of sending emails, especially when you're sending close to 60k a month. And, your server losing reputation over spammy emails too... I weighed the costs and benefits; every community is different. Furthermore, I'm not implementing this everywhere.

[Suki]

You don't actually need to weight anything. You can prevent sending emails AND avoid hitting your DB at the same time, no compromise is needed.

It is great that you want to do things by yourself, I'm like that too but at some point you will have to take the advice from others, in this case you have the attention of two former devs who had actively worked on this stuff before. You already coded your function, you know you did it, great, now take the advice.

[Biology Forums]

You advised

1) don't mess with sendmail, sendpm -- check
2) record sessions in a table, use as flood control (which also uses queries) -- check

I am listening that's why I came here.

[Arantor]

Except what we advised isn't what you implemented, but we should know better than trying to help you at this point because we can guarantee you won't listen to us.

[Suki]

Except what we advised isn't what you implemented, but we should know better than trying to help you at this point because we can guarantee you won't listen to us.

Sadly yes, the hopeless me fell unusually optimistic today

http://php.net/manual/en/reserved.variables.session.php

[Biology Forums]

sessions are ideal if you want to prevent the same user from sending information, but it wouldn't work if you want to prevent multiple users from activating a function

[Suki]

This is for everyone else out there curious about how PHP works.

In PHP world there is no concept of "multiple users". One of the fundamental things about PHP has to do with managing a single request at a time.

Whenever you hit a PHP page, the HTTP Server (Apache, nginx, ISS, etc) behind it creates a separate process for each request. Then it calls PHP and tells it to execute the needed .php file  (in SMF's case the file is almost always index.php) PHP then executes the code on that file and does blocking I/O calls, ruturns the result and Apache send it back to the client.

This means there is one process per request, no more, no less. This is partially why PHP is so popular, it is a simple concept and works OK (for small apps anyway).

What does this mean for the regular PHP coder?  well, it means you only have to worry about YOUR request and your request alone.

You don't have access to other people's request, you cannot do anything about other people's requests. All you have to do is worry about yours. How many calls to the db YOUR request does, how much memory it consumes, etc.

So, in resume, don't think about others, think about yourself.  A chessy allegory would be: how can I make the world a better place today? each action that YOU do (you as in your request) helps the server and therefore you should do it whenever possible.

This is when $_SESSION kicks in.

session are special vars that outlives requests and are widely used to preserve data across them. In this case, a session can be used to limit the amount of requests each user might perform. Limiting the amount of request and db calls PER user.

[Biology Forums]

I'm not going to judge you for misunderstanding the purpose behind what I was doing. Arantor did too after the first post, so I hope you read my clarification post before replying. I also appreciate taking the time to explain sessions -- I know what they are, but your perspective was helpful nonetheless.

Let's pretend user 2 commented on user 1's profile. User 1 gets an email notification. User 1 ignores the email or doesn't check this email address too often -- in fact, he/she forgets to login for weeks. All the while, user 3, 4, and 5 contact user 1 as well. Here's where my dilemma starts. I wanted to create a system that would prevent user 1 from getting more emails until he logs back in. Only then he would be sent more emails as they come. I don't think session reading has anything to do with it.

[Suki]

I'm not going to judge you for changing what you want every time you post. Or fighting and arguing instead of clearly explaining what you want.

Same logic still applies, each user posting to the same profile is still a request, a single request.

Anyway, same principle, instead of saving the current user ID, store the profile owner ID in a cache entry. Heck, even storing them as a profile setting or a $modsetting will be much better than what your function currently does.  Delete that entry next time the profile owner returns.  If the entry still exists it means the user hasn't returned so don't send anything.  There you go, no calls to the db, no messing with emails either.

And then you still have a problem with the current user hitting the send button multiple times...

[Biology Forums]

I don't see why I should muck up the settings table when I can just create one exclusively for this. In addition, creating an exclusive table for this project at least would allow me to record different types of miscellaneous notification -- i.e. gallery comment, gallery favorite, profile comment, etc. I still want the end user to receive the emails if they're addressing different things. I just don't want them receiving a million emails telling them different people have commented on their profile over a period of, say 1 year, if they never cared to login in the first place.

I'm not going to judge you for changing what you want every time you post.

Also to be clear, I *never* changed my mind throughout the whole conversation. You never bothered reading the conversation. That's why you were confused and why you ended up with practically the same conclusion.

Also, I have no idea why Arantor's approach to solving this problem suddenly switched once you joined the conversation. We were on the same page. Seems kind of weird to me.

[Arantor]

My approach never changed, you just misunderstood it all the way through.