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