You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Saminda Wijeratne <sa...@gmail.com> on 2014/04/15 15:48:03 UTC
Airavata Thrift API Review - Experiment Object
I started working on the final distribution for the client and in order to
perform verifications I added some samples. While writing the samples (i.e.
copy pasting it from elsewhere :)) I noticed that the Experiment has
following constraints,
- An experiment input has a data type property which does not have any
relevance at the time of creating/launching
- Compulsory to setup output of the experiment at the time of
creating/launching
- Compulsory to setup scheduling information at the time of
creating/launching
These make a potential 5-6 lines of code (which is actually needed to
launch the experiment) in to 20+ lines of code (even with the supporting
util classes we have introduced). Any suggestions on usability aspect on
this?
Re: Airavata Thrift API Review - Experiment Object
Posted by Marlon Pierce <ma...@iu.edu>.
5-6 lines > 20 lines for usability.
Marlon
On 4/16/14 7:53 AM, Suresh Marru wrote:
> On Tue, Apr 15, 2014 at 9:48 AM, Saminda Wijeratne <sa...@gmail.com>wrote:
>
>> I started working on the final distribution for the client and in order to
>> perform verifications I added some samples. While writing the samples (i.e.
>> copy pasting it from elsewhere :)) I noticed that the Experiment has
>> following constraints,
>>
>> - An experiment input has a data type property which does not have any
>> relevance at the time of creating/launching
>>
> Very true, this has to be accessed during the configuration but no point
> passing it along.
>
>
>> - Compulsory to setup output of the experiment at the time of
>> creating/launching
>>
> This is certainly a bug. GFac should be able to fetch these details from
> registry/app catalog and not expect client to send them.
>
>
>> - Compulsory to setup scheduling information at the time of
>> creating/launching
>>
> This has to be optional and not mandatory. For now, since there is no
> scheduling knowledge in Orchestrator, we may have to send this. So I think
> we should live with this for now and plan to move this logic into
> orchestrator pretty soon.
>
>
>> These make a potential 5-6 lines of code (which is actually needed to
>> launch the experiment) in to 20+ lines of code (even with the supporting
>> util classes we have introduced). Any suggestions on usability aspect on
>> this?
>>
> I agree we should be back to 5-6 lines.
>
> Suresh
>
Re: Airavata Thrift API Review - Experiment Object
Posted by Suresh Marru <sm...@apache.org>.
On Tue, Apr 15, 2014 at 9:48 AM, Saminda Wijeratne <sa...@gmail.com>wrote:
> I started working on the final distribution for the client and in order to
> perform verifications I added some samples. While writing the samples (i.e.
> copy pasting it from elsewhere :)) I noticed that the Experiment has
> following constraints,
>
> - An experiment input has a data type property which does not have any
> relevance at the time of creating/launching
>
Very true, this has to be accessed during the configuration but no point
passing it along.
> - Compulsory to setup output of the experiment at the time of
> creating/launching
>
This is certainly a bug. GFac should be able to fetch these details from
registry/app catalog and not expect client to send them.
> - Compulsory to setup scheduling information at the time of
> creating/launching
>
This has to be optional and not mandatory. For now, since there is no
scheduling knowledge in Orchestrator, we may have to send this. So I think
we should live with this for now and plan to move this logic into
orchestrator pretty soon.
>
> These make a potential 5-6 lines of code (which is actually needed to
> launch the experiment) in to 20+ lines of code (even with the supporting
> util classes we have introduced). Any suggestions on usability aspect on
> this?
>
I agree we should be back to 5-6 lines.
Suresh
Re: Airavata Thrift API Review - Experiment Object
Posted by Marlon Pierce <ma...@iu.edu>.
On the broader topic, I think our best chance of balancing simplicity
vs. flexibility is to build lots of examples and thoughtfully review
them. I don't think we want overlay APIs as this will become unmanageable.
Marlon
On 4/16/14 7:05 AM, Saminda Wijeratne wrote:
> Thanks Dave for sharing your php experience. The way I see it is that at
> some point documentation will start playing a major role for a gateway
> developer. But at this point I think these are more fundamental usability
> issues which we should try to make them more intuitive. To be honest I feel
> like we are going around circles (battle between simplicity and
> flexibility).
>
> Chathuri introduced the idea of util classes for the Java client of the
> thrift API to gap simplicity needed for the gateway developer from the
> flexible API. Dave, do you think a similar approach would help a gateway
> developer using php? Idea here is not to introduce an overlaying API, but
> to allow simplifying trivial tasks through some helper functions.
>
>
> On Tue, Apr 15, 2014 at 9:42 AM, Reagan, David Michael <dm...@iu.edu>wrote:
>
>> My PHP code uses ~28 lines to create an experiment. The Thrift-generated
>> code is quite confusing, so it’s difficult for me to tell what is really
>> required. Are there sensible defaults for some of an Experiment’s
>> properties, or can some of them be filled in automatically somewhere else
>> down the line? As a gateway developer, how would I know that?
>>
>>
>>
>> Dave
>>
>>
>>
>> *From:* Saminda Wijeratne [mailto:samindaw@gmail.com]
>> *Sent:* Tuesday, April 15, 2014 9:48 AM
>> *To:* dev
>> *Subject:* Airavata Thrift API Review - Experiment Object
>>
>>
>>
>> I started working on the final distribution for the client and in order to
>> perform verifications I added some samples. While writing the samples (i.e.
>> copy pasting it from elsewhere :)) I noticed that the Experiment has
>> following constraints,
>>
>> - An experiment input has a data type property which does not have any
>> relevance at the time of creating/launching
>> - Compulsory to setup output of the experiment at the time of
>> creating/launching
>> - Compulsory to setup scheduling information at the time of
>> creating/launching
>>
>> These make a potential 5-6 lines of code (which is actually needed to
>> launch the experiment) in to 20+ lines of code (even with the supporting
>> util classes we have introduced). Any suggestions on usability aspect on
>> this?
>>
Re: Airavata Thrift API Review - Experiment Object
Posted by Saminda Wijeratne <sa...@gmail.com>.
Thanks Dave for sharing your php experience. The way I see it is that at
some point documentation will start playing a major role for a gateway
developer. But at this point I think these are more fundamental usability
issues which we should try to make them more intuitive. To be honest I feel
like we are going around circles (battle between simplicity and
flexibility).
Chathuri introduced the idea of util classes for the Java client of the
thrift API to gap simplicity needed for the gateway developer from the
flexible API. Dave, do you think a similar approach would help a gateway
developer using php? Idea here is not to introduce an overlaying API, but
to allow simplifying trivial tasks through some helper functions.
On Tue, Apr 15, 2014 at 9:42 AM, Reagan, David Michael <dm...@iu.edu>wrote:
> My PHP code uses ~28 lines to create an experiment. The Thrift-generated
> code is quite confusing, so it’s difficult for me to tell what is really
> required. Are there sensible defaults for some of an Experiment’s
> properties, or can some of them be filled in automatically somewhere else
> down the line? As a gateway developer, how would I know that?
>
>
>
> Dave
>
>
>
> *From:* Saminda Wijeratne [mailto:samindaw@gmail.com]
> *Sent:* Tuesday, April 15, 2014 9:48 AM
> *To:* dev
> *Subject:* Airavata Thrift API Review - Experiment Object
>
>
>
> I started working on the final distribution for the client and in order to
> perform verifications I added some samples. While writing the samples (i.e.
> copy pasting it from elsewhere :)) I noticed that the Experiment has
> following constraints,
>
> - An experiment input has a data type property which does not have any
> relevance at the time of creating/launching
> - Compulsory to setup output of the experiment at the time of
> creating/launching
> - Compulsory to setup scheduling information at the time of
> creating/launching
>
> These make a potential 5-6 lines of code (which is actually needed to
> launch the experiment) in to 20+ lines of code (even with the supporting
> util classes we have introduced). Any suggestions on usability aspect on
> this?
>
RE: Airavata Thrift API Review - Experiment Object
Posted by "Reagan, David Michael" <dm...@iu.edu>.
My PHP code uses ~28 lines to create an experiment. The Thrift-generated code is quite confusing, so it’s difficult for me to tell what is really required. Are there sensible defaults for some of an Experiment’s properties, or can some of them be filled in automatically somewhere else down the line? As a gateway developer, how would I know that?
Dave
From: Saminda Wijeratne [mailto:samindaw@gmail.com]
Sent: Tuesday, April 15, 2014 9:48 AM
To: dev
Subject: Airavata Thrift API Review - Experiment Object
I started working on the final distribution for the client and in order to perform verifications I added some samples. While writing the samples (i.e. copy pasting it from elsewhere :)) I noticed that the Experiment has following constraints,
- An experiment input has a data type property which does not have any relevance at the time of creating/launching
- Compulsory to setup output of the experiment at the time of creating/launching
- Compulsory to setup scheduling information at the time of creating/launching
These make a potential 5-6 lines of code (which is actually needed to launch the experiment) in to 20+ lines of code (even with the supporting util classes we have introduced). Any suggestions on usability aspect on this?