I like the idea to have a single point of access. That would improve maintainability and makes the code easier to understand. Thus +1.
On Thu, Jul 16, 2015 at 4:45 PM, Matthias J. Sax < [email protected]> wrote: > Hi, > > I just had a look into CliFrontend and Client and it seems to me, that > there is no uniform design. > > For example, CliFrontend uses Client to execute "run" and "info" > command. However, for "cancel" and "list" it does not (because > org.apache.flink.client.program.Client) lacks those methods. > > I would recommend to extend Client and adapt CliFrontend. > > There is already a pull request for "cancel": > https://github.com/apache/flink/pull/642 > However, this PR does not adapt CliFrontend and I am not sure if it will > be finished at all. A three week old discussion resulted in no progress. > > In the current pull request for the new STOP signal, there is also some > mess with this regard. CliFrontend does not use Client.stop() -> I will > update this soon (this issues was the trigger to discover this "mess"), > or include those changes into this work (if we start it). > > Additionally, we might want to uniform WebClient and job manager > WebFrontend, too. I have an open PR that changed WebClient to use > CliFrontend to avoid code duplication. But now, this seems not the right > way to go. JobManagerInfoServlet duplicate this code, too. > > I think Client should be the unique class that offers methods for all > request and is used by all other clients. > > What do you think about this? > > > -Matthias > >
