[Catalyst-dev] Paging Ash Berlin

[J. Shirley]

On Thu, Oct 9, 2008 at 6:09 AM, John Napiorkowski <jjn1056 at yahoo.com> wrote:
>
>
>
> --- On Wed, 10/8/08, Ash Berlin <ash_cpan at firemirror.com> wrote:
>
>> From: Ash Berlin <ash_cpan at firemirror.com>
>> Subject: Re: [Catalyst-dev] Paging Ash Berlin
>> To: "Development of the elegant MVC web framework" <catalyst-dev at lists.scsys.co.uk>
>> Date: Wednesday, October 8, 2008, 9:15 PM
>> On 9 Oct 2008, at 01:53, Matt S Trout wrote:
>>
>> > On Wed, Oct 08, 2008 at 08:25:59PM +0200, Bruno Czekay
>> wrote:
>> >> Hi Matt
>> >>
>> >> Wiadomość napisana w dniu 2008-10-05, o godz.
>> 12:42, przez Matt S
>> >> Trout:
>> >>
>> >>> That's why MooseX::JobQueue was written -
>> but ash didn't have time
>> >>> to
>> >>> clean it up and release it before he left
>> Shadowcat to join a
>> >>> startup.
>> >>>
>> >>> Volunteers to help finish it up would be
>> -very- welcome.
>> >>
>> >> Lately I started some deeper digging into Moose,
>> so... if you don't
>> >> have any better volunteer around, maybe I could
>> try to do something
>> >> useful?
>> >
>> > That would be awesome. Well volunteered :D
>> >
>> > Ash, please assist this man :)
>>
>> Whut? I'm awake? Who's president?
>>
>> The code as it stands is in
>> http://code2.0beta.co.uk/moose/svn/MooseX-JobQueue/
>>
>> Things that need doing
>>
>> 1) Renaming to App::JobQueue (since its not really a Moose
>> eXtension)
>> 2) Reading over the docs to check they still make sense
>> 3) Seeing if its at all useful to what you want it to do :)
>> 4) I've got a couple of small patches sitting somewhere
>> to apply.
>> 5) Possibly move to a different SVN space. Of minor
>> impotantce tho.
>> 6) ?
>> 7) profit!
>>
>> -ash
>
> Count me in on this as well.  We are using a version of this at $work and probably have some useful feedback.  I'm not sure what the current state is, but stuff we'd like to have (ie I can work on) would be better prioritization of jobs and possibly detangling this from DBIC so that DBIC would be one of many possible storage engines.
>
> Other, lower priority stuff would include some sort of admin deamon to help collect reporting and to upgrade or query stats.
>
> Sincerely,
> John Napiorkowski


I really really really don't want to start a (very much so offtopic)
flamewar, but I would like to get a discussion going about this versus
TheSchwartz.  It seems roughly similar (at least in function).

Here are the features that TheSchwartz has that I didn't see in
MooseX::JobQueue (and yes, please name it something other than
MooseX::JobQueue)

The following are handled because of Data::ObjectDriver, but want to
list them as features anyway:
1. Partitioning of jobs in the database
2. Built-in replication handling

General stuff:
3.  Doesn't rely on POE; just has its own loop.  I can see the
benefits to using POE but it seems like unnecessary overhead for a
jobqueue that has workers that should simply do work and nothing else.
 It seems the scripts to control workers would "have more" in them
(not sure if this is a bad thing, just want to start a discussion on
pros/cons)
4.  Why does the job get a ResultSet?  This seems like a very odd and
strict tie into DBIC that doesn't seem to make much sense, tbh.  As
John said, tying it to DBIC limits its applications.  Could the job
just not get a HashRef inflated struct and iterate over it without
objects?  Performance hits should be limited as much as possible, IMO.

-J