API Design

This page is for discussing changes to the vistrails API. Specifically to make it easier to use with scripting.

• Create layered API with interactive API on top of scripting?
  • [TE]
    • I don't see how this would work. For scripts, the way we are currently thinking about them, would not interface strongly with vistrails. What we currently have is a vistrail api. For scripting, I would like to have just a module API with an executeModule method that:
      • Sets parameters and inputs
      • Creates and executes a vistrails module
      • Makes outputs available
    • In a script we only need to call modules. Is there other things we would like to do?
    • We could also have a more integrated version of scripts where provenance is recorded? But this would require more control of the python script.

• [RR]
  • API for embedding/extending/controlling VisTrails
    • Would be used by other tools like DAT, and packages like the spreadsheet which interact strongly with VisTrails
    • Would probably resemble what we currently have
    • Can be a bit more involved (and unstable?)
  • "library" API, used in scripts to create/load/run pipelines or vistrails (+ IPython magics)
  • API for generated scripts, used to run modules that couldn't be translated
    • This is what I get from TE's description above
    • Why do we need this?