Think about the nature of the communication between the server computer running your script and your user's browser running on a computer which may be on a different continent across the far side of the world from your server. In particular, how is the user closing the browser window they are using going to affect the script running on a different machine. The internet uses a fair degree of magic to get its job done, but with a little thinking and investigation you can generally at least appreciate the nature of the magic and its limitations.
Perl is the programming world's equivalent of English
| [reply] |
| [reply] |
Personally, I suggest that a CGI script should not carry out long-running activities such as “sending 100 emails.” To my way of thinking, “a web-page is a user inteface; nothing more.” If you have something that takes a long time to do, I suggest that you set up some kind of persistent daemon process that is responsible for doing it, and have it (say) listen on a pipe for some instruction ... coming from the web site or what-have-you ... that tells it to start doing it. All that the web-page needs to do is to confirm to the user that the request has been successfully posted (to the daemon).
The entire notion behind the HTML protocol is that you “submit a request, get a response, then fuhgeddaboudit.” ...
Request => Response ... Finis.
... and, so, that is precisely how I would structure the process that enables the user to request that 100 emails should be sent “real soon now.” Don’t make him wait for it. Heck, don’t allow him to wait for it. That’s not what HTML is for.
| |
| [reply] |
Thanks so much for this response. You're right. I need to figure out a different way to do it.
| [reply] |
