On Fri, Apr 30, 2010 at 3:59 PM, Steve Kleiman <st...@prodhub.com> wrote:
> That's definitely my fallback if necessary. I really like using the > Catalyst-centric option because it's easier for my brain to > compartmentalize. It keeps the email dispatching process consistent with the > rest of the Email::Template paradigm used throughout my app. > > Also it's not just for email I'm using RunAfterRequest...it's a bunch of > slow database processing that leads up to the generation of the email. So I > was hoping to drop the whole bit into RunAfterRequest instead of having a > cron job deal with it. Keeps all my stuff in one place and for a Catalyst > newbie that's a nice thing (if it works). > Ya, it's a fine line. I tend to think Catalyst's job is to handle a request and return the response as soon as possible and then move on to serve another request. But, if you have processes to spare then why not use them? Might need to think about other things like how a long running process might effect the need to restart the sever, etc. Job queues are nice. -- Bill Moseley mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
