API Design

From VistrailsWiki
Revision as of 17:22, 6 August 2014 by Remi (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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?
  • [DK]
    • Agree with RR that the general VT API focus should be used for embedding/extending/controlling VisTrails
    • The current API combines some stateful commands (new_vistrail/execute_workflow) with the script-based workflow construction
    • We need to improve this; I think there is too much that has to be done with the controller right now.
    • WRT the module scripting API TE proposes, I think this is mostly orthogonal
      • I see TE's point that running a module outside of the workflow structure is not straightforward right now
      • This could be another focus and would be specifically for the scripting work

Problems:

Work in progress on branch new-api. Notebook.