On Thu, Jan 30, 2014 at 9:34 PM, Amila Jayasekara <[email protected]>wrote:
> We definitely need sample code which demonstrate the use of Airavata API. > But I am not sure whether to call them patterns or API documentation. > Its definitely not API documentation. We so far have solve several gateway problems using Airavata and and each is different on its own although the ultimate goal was the same. I just think that it would be very useful to have these variations documented. I used the word "pattern" because even with different variations there will be other gateways which may be following the same variation. Thus the word "pattern". > > We do not need to create a "very" generic API but the API should be > intuitive enough for a person with high-level picture in mind to understand > and guess which functions to call to get something done. > In my experience these days most developers google for examples/solutions/algorithms (atleast to get an idea how to do something) rather than go through API documentations and designing and implementing from scratch. And the Airavata API (Thrift version or otherwise) inherits a context of usage which pops the questions like "when to use what and how". There is so many features just for an Airavata experiment launch which we have implemented because of user requirements which we cannot expect users to be intuitive enough to figure-out the importance of using them when, why and how. > Thanks > Amila > > > On Thu, Jan 30, 2014 at 11:54 PM, Saminda Wijeratne <[email protected] > >wrote: > > > I'm thinking of the reasons why we are having trouble getting a proper > API > > to work smoothly is that, > > > > > > 1. We are trying too hard to generalize when its probably not possible > > to do > > 2. When we keep trying to see the big picture we miss the little > things > > in the gateways that makes the usage of the API easy or hard for the > > developer. > > > > eg: Not all gateways look at "Experiment Launch" use case as passing an > > application name and its input to launch the experiment. (I think we've > > came across many variations for this use case) > > > > - the inputs could be in different form (could be actual files) or > just > > optional > > - application name could be just a reference to a parameter of a > global > > application > > - part of the launch process may have runtime dependencies which > gateway > > requires to participate > > - the gateway might want more control over the launch configurations > at > > runtime. > > - ... > > > > I think devs see it as a mismatch of the API for their gateway which > > discourages the effort to use the API. > > > > IMO part of our Thrift API effort should be to document these with the > > solutions similar to Java Patterns. > > > > In short, instead of trying to come up with a general API to make > everyone > > happy we provide solution patterns for a gateway use case which will have > > multiple variations. (solution pattern would be use of the API + > supporting > > code which handles the variation) > > > > wdyt? > > > > > > Regards, > > > > Saminda > > >
