Attendees: Kandace, Mike, David, Kenton, Craig

Agenda:

  • Update on developer support requirements analysis
  • Recommender service

 

Development scenario: Federated search against Clowder and Globus Publish (a real possibility with DIBBs T2C2 and NIST MDF efforts, assuming enough of Globus publish's source is available - checking!)
Note: this is one of many possible examples.  Jim's example is similar to this one.  The TERRA example is also relevant, however largely touches only on the first use case (I think).

Two use cases:

  • Building something new
    • Need a workspace and tools to create a new service
    • Building something against an existing service
    • Approach 1 to above scenario: a new search tool is created that knows how to interface with both the Clowder API and the Globus API.  The workbench is used to deploy test instances of each to work against.
  • Extending something that exists
    • Approach 2 to the same scenario: Clowder is modified to support an OAI-PMH interface (i.e. its API is extended).  Similarly Globus Publish is extended (if need be) to also support an OAI-PMH interface.  Any search tool capable of talking OAI-PMH now can be used.  The workbench is used to deploy these modified versions and test the ability search across both (possibly with a search tool deployable in the workbench as well).

 

Next steps:

  • Mock-up(s) (6/14)
    • Some considerations for Mock-ups:
      • Attempt to link as closely as possible with the current workbench (make the current tool richer vs making two weaker tools)
      • Minimize impact to current usefulness of workbench (i.e. should not overtly alter how one currently does things if not a developer)
      • Web based IDEs already exist so what's the value-add (i.e. being able to deploy the IDE from the workbench isn't enough)?  Options to consider:
        • Make it trivial to get the source code for the services listed in the workbench (not for all versions, just the current "master" or "release")
          • Above scenario: I lost or forgot, and/or for the life of me can't find where the globus publish code is even though I have been told multiple times it is available as open source.  Sent an email to Ben on the Globus team to get the URL to the repo.  This could be a lot easier (especially for someone who doesn't know Ben).
          • Don't worry about being able to push back, forking is fine
        • Make it trivial for someone adding a service to specify which codebase(s) a developer would use
          • This should then become a part of the service creation process (i.e. specifying the source code repo(s) that go along with it) - perhaps an optional part in case the code isn't available for everything we want to consider
        • Make it easy to work with the code from multiple services simultaneously from within one instance of the IDEA
          • Above scenario - Approach 2: like projects in eclipse I can have the Clowder code open and the Globus Publish code open at the same time (perhaps using similar code in both services, copying/pasting/adapting to fit).
        • Make it easy to test their changes (i.e. press a run button and re-deploy the service in the workbench to try out)
          • Above scenario - Approach 2: Modified Clowder to support OAI-PMH, click compile/deploy, can test with a OAI-PMH search tool available in the workbench (assuming there is such a thing) by deploying it along side.  Perhaps it fails to interface, can then debug and repeat...
        • Make it trivial to push developed code back into the workbench as a new service
          • Make it easy to save work to somewhere relevant (on nebula?, github?)
          • Package as a service (both as a container and with the source) back to the workbench
      • Consider the role admin/developer (i.e. the person who signs up can be the developer directly)
  • No labels