Jacques, Any thoughts on this?
---------- Forwarded message ---------- From: Srihari Srinivasan <[email protected]> Date: Wed, Aug 7, 2013 at 6:30 PM Subject: Next steps on the REST API To: [email protected] Hi Jacques, Summarizing a couple of questions and changes needed. - Is there any overhead to instantiating a new DrillClient, connecting to a drillbit and closing the connection per http request? Jersey creates a new instance of the Resource class for each request and the DrillClient will get instantiated per request unless we make it a static variable. - I am assuming that the DrillClient which will be instantiated from the http layer will always connect to the co-located/localhost Drillbit With respect to the DrillClient we'll need the following methods to support the async style interaction. If we agree to supporting this design I'll create a JIRA for this - - new DrillClient().submitQuery(QueryType, Query String) that returns the *QueryId* *and continues to execute in the background* - new DrillClient().getStatus(queryId) that returns a Status object. It could just return *IN_PROGRESS, SUCCEEDED and FAILED* for now. And some way to know why it failed in case it did. - new DrillClient().getResults(queryId) that returns *QueryResultBatch*as it is doing now. While the api I've speced out above is the ideal one I guess this will require more time and effort to implement it as suggested. Especially for the getStatus and getResults methods as it implies that the state of a query's lifecycle will be held/persisted by someone. Is the server already maintaining some state for tracking the lifecycle of a query which can be exposed? Hari
