Hi Devs,

We had some offline discussions regarding Airavata API and following are
 some of the improvements that we decided on.

   - *Change the name of AiravataManager in AiravataAPI interface*
   - *Providing utility class for creating the ServiceDescriptor and all
   the application creation (Look at the util class <DescriptorUtil> provided
   in REST service).*
   - *saveDeploymentDescription method should jus get a Host and Service
   descriptor objects rather passing the names.*
   - Instead of having single save method for both add and update, we
   should have separate methods for those functionalities
   - *Remove isExist check from the save methods, ideally when we introduce
   above add and update functions separately, this will become obsolete.*
   - *Use ApplicationDescriptor in all the places.*
   - *Overload saveWorkflow function and pass the URI of a workflow path.*
   - *Add the method - getWorkflowTemplateIds in integration tests.*
   - *Adding tests for workflow metadata saving in integration test.*
   - *We need fill up all the arguments in runExperiment method to show the
   users how they are suppose to use the method.*
   - *Adding tests for querying by Experiment name.*
   - *Add tests for all the runExperiment overloaded methods.*
   - *Put API comments for runExperiment and other methods.*
   - *For the test case we need implement the pulling and pushing the
   status of the workflow. Pulling from registry and get the pull messages
   from notification.*
   - *Add a stopMonitoring function to ExecutionManager*
   - *Improvements to runExperiment() method
   *
      - we need to get rid of all 6 overloaded methods
         - keeping the simple one as it is and passing a bean object for
         advance cases
         - giving different names for method signatures if the usage for
         the API user is different
         - having fine grained exception types
      - ContextHeaderBuilder
         - revamp the schema
         - get rid of unused parameters in ContextHeaderBuilder class
         - instead of having single ContextHeaderBuilder class, have
         different classes according to usage
            - scheduling
            - output handling
            - security

Plan is to do all the suggested improvements before 0.6 release except for
security section of ContextHeaderBuilder class improvement.

All your feedback is most welcome.

Thanks and Regards,
Chathuri

Reply via email to