Closed dotasek closed 5 years ago
cannin
commented
7 years ago I'm not sure if part of the plan is to produce R code to interact with a Swagger API. There is an effort to produce a codegen for R; it is relatively new.
https://github.com/swagger-api/swagger-codegen/issues/6520
Testing it would be useful, I think thus far it has been largely applied to the simple Swagger Pet example.
dotasek
commented
7 years ago @cannin We have experimented a little with auto-generated code from CyREST's Swagger, but didn't get beyond just trying it out. Perhaps trying it with a smaller App would be a more manageable experiment.
dotasek
commented
7 years ago @bdemchak made a suggestion in another context that I think could remove some complexity from my earlier suggestions:
Would the problem be best solved by a link on the App Store app page to the libraries supplied by the app writer? These should also be available and discoverable in the public repositories R/Python ... but having them discovered via the App Store would be good, too. I don't think we want to reinvent repository/discovery services already known to communities, but we do mean to reduce friction. This isn't a proposal ... it's philosophy that could be ambient in a proposal discussion.
It would make lots of scripters' lives easier if each Cytoscape app with automation came with its own functions in R and/or python.
There are two approaches I think would work, with a few notes.
Make each library a resource in the app, and provide it as an endpoint. For example, the R library for Diffusion would be loadable from
http://localhost:1234/diffusion/v1/r. We do this in CyREST to serve the SwaggerUI, so it should be able to be done similarly for R/Python files. This has the advantage of not requiring an internet connection to load the library. The disadvantage is that URL based loading is possible but discouraged in a lot of internet discussions due to security concerns (which I think can be bypassed by saying, it's on localhost... who can you trust, if not localhost?)As with our R demos, we can load directly from GitHub. This would ensure constant delivery, and is supported by both R and Python communities. The disadvantage is that more vigilance would have to be paid to ensure that no breaking changes are introduced if the github code changes while old copies of the App are still in use.
Possibly linked to both of these could be CyREST resources that keep track of the apps installed, and their libraries if they are available. Combined with functions in R and python, scripters could query for what apps are available, and install/load their libraries on the fly.