View source for Slicer 3.0 Some preliminary discussion points

* Define what is a "case" (a collection of data for processing). For example:
** a MRML file with URL references that the pipeline elements resolve, or,
** a zip file with a MRML file and associated data inside of it.

Also, what MRML functionality do we need for real-world cases processed outside of Slicer? Is ITK-like functionality a good place to start?

* Provide a way to declare and fill in a pipeline's "case variables" (parameters that vary by case) and "global variables" (parameters that control the execution of the pipeline itself, such as where to run, how many processes, simple credentials, etc). Here's where pipeline parameter introspection comes in, but it doesn't have to be really complicated for this pass.

* Enough event loop to monitor dispatched processes. For short-running processes, it might be just exec and wait. For long-running processes that have remote job control, you might just poll the scheduler with a ticket and wait for a response. LONI and Grid experts can help here. For shared libraries, you could do a thread.

Could this be implemented as a single PipelineMonitor object?

* UI for parameter specification and case manipulation.

* LONI / Grid pipeline prototyping and parameter agreement.

* For a use case with many cases (say, run on a grid or cluster), is any information read or interpreted in Slicer? The case for a shared memory model proposed by Guido and Ross would seem incompatible with running 50 cases on a cluster.