Define and document general functionality and glossary

[fcastilloes]

The proposal of this library is to wrap thephpleague/pipeline implementation of Pipeline Design Pattern with an opinionated implementation. The main objective is to allow creation of several pipelines and add an interface to control the execution, allowing pipeline interruption, concatenation or replacement.

The main concepts, with an provisional naming, needed for implementation could start with the following:

• Convoy: the main interface. Should allow clients to add() named pipelines and run() named pipelines.
• Waybill: should keep the planned execution path and the history of execution. Planned path should be changeable.
• Checkpoint: any executable implementation provided by clients should implement this interface.
• Valise: payload to send to every Checkpoint. Should be abstract and implemented by clients.
• Driver: should read the Waybill to execute the following Checkpoint.
• Courier: should be also a dependency of Checkpoints so clients can send orders to control the Waybill.
• Stamp: each time the convoy reaches a Checkpoint, the Valise is opened and processed, a Stamp is added to the Waybill indicating that the Checkpoint fulfilled its duty. The Stamp is abstract and can be of different types to indicate success, failure, error or any status raised from the Checkpoint.

[rvegas]

I don't really like _Auxiliary_, I think it does not give the right meaning to the actual function behind it. What about _Superintendent_ or _Auditor_?

http://www.thesaurus.com/browse/scrutinizer?s=t

[fcastilloes]

I didn't really like Auxiliary as well. Those are better, but in the wikipedia entry for Waybill we have Carrier, which in the thesaurus throws Courier, which I think sounds great, as it will be responsible for the message to reach its destination.

[fcastilloes]

So are you ok with the rest of the names? I wasn't too sure about Valise.

[rvegas]

I understand Valise, its cool. Also courier seems nice.

[fcastilloes]

Additional element:

• Seal: each time the convoy reaches a Checkpoint, the Valise is opened and processed, a Seal is added to the Waybill indicating that the Checkpoint fulfilled its duty. The Seal is abstract and can be of different types to indicate success, failure, error or any status raised from the Checkpoint.

The Courier should be able to search the Waybill for Seals if asked by a Checkpoint.

[fcastilloes]

It would also be needed a CheckpointProxy so they can be assigned yo the Waybill and lazy loaded when requested by the Driver.

[rvegas]

About _Seal_ wouldn't you rather use stamp?

[fcastilloes]

Instead of CheckpointProxy we could better have a Destination, which would be a simple value object that driver could use to build a Checkpoint.

So, Driver should be an interface that a client could implement to add their own rules. A ClassDriver could be included to get a Destination with the classname of the Checkpoint

interface Driver {
  /**
   * @param Destination $destination
   * @returns Checkpoint
   */
  public function get(Destination $destination);
}

[fcastilloes]

Thinking about if Destination should implement a Composite Pattern to add subroutes and how it should be implemented.