airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Airavata API review
Date Thu, 20 Dec 2012 02:08:02 GMT
I agree with Chris. My opinion is discussions should be discouraged but are ok to have as long
as they are properly summarized and solicited for further comments on the mailing list. But
*decisions* are certainly not acceptable. Lets please use mailing lists as much as possible
for reviews. 

Hi Chris,

Thanks for pointing this out, not to single out Chathuri here, but these discussions have
been more prominent these days and lets all collectively avoid them. I will be more vigilant
as well. 

Suresh

On Dec 19, 2012, at 7:00 PM, "Mattmann, Chris A (388J)" <chris.a.mattmann@jpl.nasa.gov>
wrote:

> 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" <kamalasini@gmail.com> 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
> 


Mime
View raw message