Type Members

1.  trait BindingProvider extends AnyRef

   A data provider.

   A data provider.

   This trait is used to expose the input variable requirements of a pipeline.

2.  class BindingSpecification extends AnyRef

   Specify the required bindings for steps.

   Specify the required bindings for steps.

   The core engine doesn't care what bindings are passed to steps. If you have a step that requires a specific set of bindings, you can declare that explicitly. Once declared the pipeline engine will assure that a binding is provided.

   Unlike ports, which have cardinalities, all that you can specify for bindings is that they are required. You cannot forbid bindings; steps must ignore "extra" bindings that might be provided by the pipeline.

3.  trait DataConsumer extends AnyRef

   Interface for sending outputs from atomic steps.

   Interface for sending outputs from atomic steps.

   Atomic step implementations are independent of the graph execution infrastructure.

   Steps call the receive method on this object to deliver output.

4.  trait DataConsumerProxy extends AnyRef

   A data consumer.

   A data consumer.

   This class is used to provide outputs from the pipeline. An instance of this class will be provided after the runtime is constructed. The user can call setProvider to specify where the data should be delivered.

5.  trait DataProvider extends AnyRef

   Interface for sending external data to a pipeline.

   Interface for sending external data to a pipeline.

   Call the send method on this object to deliver data.

   (This really exists just to simplify the interface to the pipeline. There's a simple proxy that sends provided data to an appropriate consumer.)

6.  class Manifold extends ManifoldSpecification
7.  trait ManifoldSpecification extends AnyRef
8.  class PortCardinality extends AnyRef
9.  class PortSpecification extends AnyRef

   Specify the valid bindings for step inputs or outputs

   Specify the valid bindings for step inputs or outputs

   The core engine doesn't care what steps are connected or what ports they're connected on. But in practice, many steps do care. If you have a step that expects to read a single document off the source port and to write a sequence of documents to the result port, it does no good to run a pipeline where those ports aren't connected.

   A port binding specification identifies the ports that the step expects to read from (or write to) and what the acceptable cardinality of documents is on those ports.

   The port named PortSpecification.WILDCARD serves as a wildcard for ports of any name

10.  trait Step extends DataConsumer with ManifoldSpecification

    An atomic pipeline step.

    An atomic pipeline step.

    Steps must implement this interface. The step lifecycle is as follows:

    1. The setConsumer method will be called. The step must hold onto the consumer object. Calling send on this object is the step's one and only way to send output to the next steps(s) in the pipeline. 2. The receive method will be called for each input item that the step receives. 3. The run method will be called after all inputs have been received. 4. If the step is in a loop, the reset method will be called between iterations.

    Steps are not required to wait until their run method is called before beginning execution. Note, however, that if a step has side effects (writing to disk, interacting with a web service, etc.) it is prudent to do so. A step may receive several inputs and then never run if some sibling step raised an exception that caused an entire container to fail.

11.  trait ViewportComposer extends AnyRef

    Decompose and recompose data for viewport processing.

    Decompose and recompose data for viewport processing.

    Viewports operate on sub-portions of a resource (some of the children in an XML document, some of the properties in a JSON object, etc.).

    The decompose method is called before the viewport processing begins. It extracts the sub-portions that should be processed and returns them. Each returned item is mutable and will be updated by the viewport processing.

    The method by which sub-portions are selected is irrelevant to the pipeline engine. Often it will be convenient to pass an expression or other data to the implementation of the composer to control the selection.

    Note: it's an implementation detail whether the items returned are pointers into the original data structure or copies of them. If they are pointers into the original data structure, then viewport steps may be able to navigate outside the confines of the sub-portion selected. For better or worse.

    The recompose method is called after viewport processing is complete. The composer reassembles the resource using the transformed portions and returns the resulting resource.

12.  trait ViewportItem extends AnyRef

    A representation of a sub-portion of a resource for viewport processing.

    A representation of a sub-portion of a resource for viewport processing.

    Each viewport item will be used by the viewport step to process a sub-portion of a larger resource.