airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Airavata Thrift API Review - Experiment Object
Date Wed, 16 Apr 2014 11:05:05 GMT
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 <dmreagan@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?
>

Mime
View raw message