airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <>
Subject Re: Airavata Thrift API Review - Experiment Object
Date Wed, 16 Apr 2014 12:49:01 GMT
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.


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 <>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 []
>> *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?

View raw message