this is not being called anywhere, not sure what it was for

anarcat authored May 31, 2010 and anarcat committed May 31, 2010

we are already saving the task in hosting-task. the reason why we were
saving in both places was to avoid a race condition where a task would
be started *while* the dispatcher would restart, which is very unlikely,
and was still possible with the existing code anyways.

now the checks are done only in hosting-task. it's more possible to have
a conflicting concurrent run of a task, but both runs would need to
start at about the same time so that the _validate() drush hooks would
run in parallel and both would check and save the task status at once.

i consider this too unlikely to desserve the current hack.

furthermore, the problem with the current code was that if the
hosting-task command was interrupted (for example through
provision_init() load checks) before it was able to save the status, we
end up with zombie tasks that are marked as running but that are gone
from the process table (because they never started properly).

mig5 authored Mar 12, 2010 and mig5 committed Mar 12, 2010

This reverts commit 8c204d5ff80259269d8e4b12516f9070b41b75a2.

anarcat authored Feb 25, 2010 and anarcat committed Feb 25, 2010

 hosting_dispatch_cmd, just use DRUSH_COMMAND

Introduce the options method to the service class. This allows you to pass values to the command line call to drush.

stop using a callback for hosting_dispatch so it can be handled using the regular drush hook sequences

all commands are now hyphen separated, and all the drush_invoke and drush_backend_invoke instances show that.