compared with
Current by Mike Willbanks
on Jun 18, 2012 13:47.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (47)

View Page History
<p>This RFC is for an addition of a new component Zend\Gearman.</p>

{note}This is currently coded as a module [mwGearman on GitHub|https://github.com/mwillbanks/mwGearman].{note}
<ac:macro ac:name="note"><ac:rich-text-body><p>This is currently coded as a module <a href="https://github.com/mwillbanks/mwGearman">mwGearman on GitHub</a>.</p></ac:rich-text-body></ac:macro>

h2. Why Zend\Gearman
<h2>Why Zend\Gearman</h2>

In [ZF1 <p>In <a href="https://github.com/mwillbanks/Zend_Gearman">ZF1 I created a utility class|https://github.com/mwillbanks/Zend_Gearman] class</a> to help us handle working with gearman and making working with workers extremely easy. I wanted to bring this same type of thing to ZF2 except as a full component. The following is the reasoning / challenges you face without having a gearman component</p>
<ul>
* Hard <li>Hard to unit test; you need a layer of abstraction</li>
* Encapsulation of worker code (future after Zend\Console)
* Better integration with the framework
<li>Encapsulation of worker code (future after Zend\Console)</li>
<li>Better integration with the framework</li>
</ul>

h2. Proposed Architecture

Abstraction to the following layers to allow further extension and possible integration with Net_Gearman
* Client
** ClientInterface and Pecl concrete class
* Worker
** WorkerInterface and Pecl concrete class
* Connection
** ConnectionInterface and Pecl abstract class (implemented by Client & Worker)
* Job
** JobInterface and concrete job class (handles getting the jobs into a suitable format)
* Task
** TaskInterface and task concrete class (you create a task to pass to the client)
<h2>Proposed Architecture</h2>

h2. Usage
<p>Abstraction to the following layers to allow further extension and possible integration with Net_Gearman</p>
<ul>
<li>Client
<ul>
<li>ClientInterface and Pecl concrete class</li>
</ul>
</li>
<li>Worker
<ul>
<li>WorkerInterface and Pecl concrete class</li>
</ul>
</li>
<li>Connection
<ul>
<li>ConnectionInterface and Pecl abstract class (implemented by Client &amp; Worker)</li>
</ul>
</li>
<li>Job
<ul>
<li>JobInterface and concrete job class (handles getting the jobs into a suitable format)</li>
</ul>
</li>
<li>Task
<ul>
<li>TaskInterface and task concrete class (you create a task to pass to the client)</li>
</ul>
</li>
</ul>

There are two primary usages, Client and Worker.

Assume you set this up with DI for this example; as it makes showing this example quick and painless :)
<h2>Usage</h2>

<p>There are two primary usages, Client and Worker. </p>
{code:php}
<p>Assume you set this up with DI for this example; as it makes showing this example quick and painless <ac:emoticon ac:name="smile" /></p>

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
return array(
'di' => array(
),
);
{code}
]]></ac:plain-text-body></ac:macro>

h3. Client
<h3>Client</h3>

<p>You create the client, connect and pass in a task to be handled. The task handles all aspects of understanding in itself.</p>

{code:php}
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$gearman = $serviceMananger->get('Zend\Gearman\Client\Pecl');
$gearman->connect();

$handle = $gearman->doTask($task);
{code}
]]></ac:plain-text-body></ac:macro>

h3. Workers
<h3>Workers</h3>

<p>The workers are receivers of messages. Currently this does not contain a BaseWorker which is the plan after Zend\Console is integrated into the trunk.</p>

{code:php}
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$gearman = $serviceMananger->get('Zend\Gearman\Worker\Pecl');
$gearman->register('myJob', 'handleJob');
echo $workload;
}
{code}
]]></ac:plain-text-body></ac:macro>

h3. Notes
<h3>Notes</h3>

<p>Everything that contains a setter of some degree does utilize a fluid API; additionally one object takes a more aspect oriented approach (Job), mainly because it becomes more consistent since the setter should only be completed through the worker and is more internals to the working of the component.</p>

h2. What's Not Complete?
* Zend\Console integration
<h2>What's Not Complete?</h2>
<ul>
<li>Zend\Console integration
<ul>
** BaseWorker <li>BaseWorker which will provide many of the things to rapidly create jobs</li>
* [Net_Gearman|http://pear.php.net/package/Net_Gearman] integration
* Mock Client & Mock Worker
* Documentation
* Unit Tests
</ul>
</li>
<li><a href="http://pear.php.net/package/Net_Gearman">Net_Gearman</a> integration</li>
<li>Mock Client &amp; Mock Worker</li>
<li>Documentation</li>
<li>Unit Tests</li>
</ul>



<p>More or less, this component will likely target a phase 2 for Zend\Console integration. Documentation and Unit Tests will come next (by doing the unit tests a mock client and mock worker would be created for the unit tests). This RFC is to get comments on design and changes prior to building out the final portions of the components.</p>