Page History

...

All combinations are possible, although some combinations will likely be easier to accomplish than others.

"Repository" - User Frontend

1. 1. user installs bookmarklet this may be restricted in modern browsers... more research is necessary
      • Pros
        • browser-agnostic
      • Cons
        
        • probably lots of learning involved here
        • user must seek out and install this
        • injecting arbitrary JavaScript into pages does not feel very secure, and has since been replaced by modern browser extensions
          • see https://hypothes.is/blog/farewell-to-bookmarklets/
          • see https://medium.com/making-instapaper/bookmarklets-are-dead-d470d4bbb626#.co504ji62
   2. user installs browser extension
      • Pros
        • more secure than bookmarklets... I guess?
      • Cons
        • probably lots of learning involved here
        • user must seek out and install this
        • browser-specific (we would need to develop and maintain one for each browser)
   3. developer(s) add a link to repo UI which leads to the existing ToolManager UI landing page, as in the NDSC6 demo
      • Pros
        • user does not need to install anything special on their local machine to launch tools
      • Cons
        • repo UI developers who want to integrate with us need to add one line to their source to integrate with us
          • Dataverse, Clowder, Globus Publish, etc

"Resolver" - API endpoint to resolve DOIs to tmpnb proxy URLs

1. 1. Serve a JSON file from disk? (this is more or less how the existing ToolManager works)
      • Pros
        • Easy to set up and modify as we need to
      • Cons
        • Likely not a long-term solution, but simple enough to accomplish in the short-term
   2. Girder?
      • Pros
        • Well-documented, extensible API, with existing notions of file, resource, and user management
      • Cons
        • likely overkill for this system, as we don't need any of the file management capabilities for resolving
   3. etcd?
      
      • Pros
        • familiar - this is how the ndslabs API server works, so we can possibly leverage Craig's etcd.go
      • Cons
        • it might be quite a bit of work to build up a new API around etcd
   4. PRAGMA PID service?
      • Pros
        • sounds remarkably similar to what we're trying to accomplish here
        • supports a wide variety of different handle types (and repos?)
      • Cons
        • may be too complex to accomplish in the short term
        • unfamiliar code base / languages

"Agent" - launches containers alongside the data on a Docker-enabled host

...