You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Chathuri Wimalasena <ka...@gmail.com> on 2012/12/19 16:00:02 UTC
Airavata API review
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
Re: Airavata API review
Posted by Saminda Wijeratne <sa...@gmail.com>.
On Wed, Dec 19, 2012 at 10:00 AM, Chathuri Wimalasena
<ka...@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
>
I've created a bean [1] for encapsulating advanced options. Please feel
free to review/comment/update on it. We will be having this on 0.6 API.
Thanks,
Saminda
1.
https://svn.apache.org/repos/asf/airavata/trunk/modules/airavata-client/src/main/java/org/apache/airavata/client/api/ExperimentAdvanceOptions.java
- 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
>
Re: Airavata API review
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Guys,
On 12/19/12 6:08 PM, "Suresh Marru" <sm...@apache.org> wrote:
>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.
Thanks appreciate it, Suresh. Not singling out Chathuri -- it was a great
job to bring this discussion back on list, just pointing out that it's a
discussion until a decision is made here. Great work keep it up guys.
Cheers,
Chris
>
>
>Suresh
>
>On Dec 19, 2012, at 7:00 PM, "Mattmann, Chris A (388J)"
><ch...@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" <ka...@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
>>
>
Re: Airavata API review
Posted by Suresh Marru <sm...@apache.org>.
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)" <ch...@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" <ka...@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
>
Re: Airavata API review
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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" <ka...@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