Re: [Catalyst] RunAfterRequest/delayed Catalyst view
Thanks for the feedback, Bill, t0m. I've got some reworking to do... -s On May 1, 2010, at 6:19 PM, Tomas Doran wrote: > > On 30 Apr 2010, at 23:22, Bill Moseley wrote: >> 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. > > +1 for that approach. That's exactly what I do :) > > Cheers > t0m > > > ___ > 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/ ___ 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/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
On 30 Apr 2010, at 23:22, Bill Moseley wrote: 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. +1 for that approach. That's exactly what I do :) Cheers t0m ___ 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/
Re: [Catalyst] Returning error codes to the user.
On 30 Apr 2010, at 23:18, Bill Moseley wrote: But, for a tiny, tiny percent a request might fail. Then the question is *why* did it fail? What WHERE condition or join failed? Just like our favorite topic premature optimization, I don't think it would be wise to write the above in multiple stages (and multiple requests to the database) just to check each step for something that almost never fails. On the other hand, it's not unreasonable for an API request to return a reason why something failed. Sure would make tech support's life easier. So, what would you recommend? Have a separate /user/$id/debug method that does a separate step-by-step of the business logic? Scrap all that really handy chaining of resultsets that works so well with Catalyst's chained actions? Given that 'a tiny, tiny percent a request might fail', why not do the step by step for the tiny failed set and then present the reason to the user for those? (Or am I missing something obvious here?) Cheers t0m ___ 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/
