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
