Difference between revisions of "API Design"
Jump to navigation
Jump to search
(Created page with '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? **…') |
|||
| Line 9: | Line 9: | ||
*** In a script we only need to call modules. Is there other things we would like to do? | *** 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. | *** 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) | |||
Revision as of 15:26, 17 July 2014
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.
- 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:
- [TE]
- [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 embedding/extending/controlling VisTrails