In my opinion, the existing Job Queue is awfully close to being suitable for my media recoding needs. Rather than recreating a very similar mechanism just for queueing media recoding jobs, I wonder if it would be okay for me to make a few changes that would make it a little more robust and suitable to my needs.

Currently, JobQueue::pop_type() just gives up on finding a job to do if it finds that the first one it has selected already got taken by a concurrent process. I believe this could be improved easily by just returning a recursive call:

if ($affected == 0) { wfProfileOut( __METHOD__ ); //used to be: return false; //but there may still be other jobs of $type we can claim... return self::pop_type($type); }

...but since this hasn't been done already, I'm afraid there's some reason for it to be as it is. This is safe and behaves as expected when no more jobs of $type exist. There's no way this could break any client code, since it has no idea whether this condition will occur when it calls pop_type. Any other reasons not to do this?

Also, I want to populate the job queue with things that cannot be run on just any machine, probably including those that currently pop() from the job queue. To prevent this from happening, I could: -make a new table structurally identical to job, and make a child class of JobQueue that just redefines a class constant containing the table name. -add a flagging column to the current job table that JobQueue::pop() checks for and skips over if the flag is on -just hardcode job types that shouldn't be claimed into pop() so they will only be taken on pop_type() calls.

I don't know how much changing database structure makes people's lives difficult at upgrade time, so I'm not sure which of these would be best in the event that my work eventually proves itself worthy of inclusion in mainline MediaWiki.

Mike