On 3/21/2011 1:48 AM, Octavian Rasnita orasnita-at-gmail.com |Catalyst/Allow to
home| wrote:
You can use any of them or Catalyst::Helper::Model::Email. The plugin is no longer
recommended.
So I see. It's a simple wrapper that just integrates Catalyst config files, and that
suits by purpose. But trying to figure out how to use it I find the underlying stuff is
deprecated.
Reading the page for Catalyst::Helper::Model::Email, and assuming that a ')' keeps getting
lost, it's just a simple to use but you look up an object via Model first. What is the
benefit of that? I suppose you can have more than one configuration pre-set, but I don't
see that happening. Is there some other advantage or conceptional purpose for making a
"feature" or "content sink" or "side effect call" presented as a Model?
The most simple way is not the best. The best way is to send the messages in a job queue
and let the worker module to send the message immediately or whenever the mail server is
free.
If you send the message directly from your application, in that moment the server might
not be free and the user would need to wait too much until the message is sent, or the
mail server might give a timeout and in that case the message is lost because the
application doesn't send it again when the mail server is free.
I like being able to get a return result so I know it was sent!
If that is not possible on a real server, is there some module already that
does this?
Hmm, maybe it depends on the mailer used? Postfix just queues the incoming message
anyway! Why am I needing to duplicate what it already does? Would another queue process
in front of it be less likely to get stuck?
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
