Hi Guys, One thing that concerns me about this thread is "offline discussions" and *things we decided upon*.
At Apache, all decisions happen on the mailing lists, so can you please elaborate? Cheers, Chris On 12/19/12 7:00 AM, "Chathuri Wimalasena" <[email protected]> wrote: >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
