Yes definitely. The client and submission code is spread out over multiple classes and different clients follow different paths. This is a bit messy right now, IMO. A big +1 to unify and restructure the client.
2015-07-16 17:52 GMT+02:00 Till Rohrmann <[email protected]>: > 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 > > > > >
