Mailing-List: contact dev-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CANMXwW27uFOBFdPOSt+o4yG2W+JYMOLbYgRbiuQYmDqefk3NMA@mail.gmail.com>
References: <55A7C37C.6020603@informatik.hu-berlin.de>
 <CAC27z=PRyhj7=K+Mz6K1g4+8vvfbmNp+Qg2SKh0vn28k1kpYmw@mail.gmail.com>
 <CAAdrtT0yeQub=iNpQf=gybwQ_iBFezEsXcPy3sSNH20Xu+4mDg@mail.gmail.com>
 <CANMXwW27uFOBFdPOSt+o4yG2W+JYMOLbYgRbiuQYmDqefk3NMA@mail.gmail.com>
From: Maximilian Michels <mxm@apache.org>
Date: Fri, 17 Jul 2015 14:47:05 +0200
Message-ID: 
 <CAGco--aEprFOPVLNY3dWw9CDfjx_HbFr+hGmhZa+ADO_Yr_iwA@mail.gmail.com>
Subject: Re: [DISCUSS] Unifying client code
To: dev@flink.apache.org
Content-Type: multipart/alternative; boundary=001a11347d2cfe85b7051b11966c

--001a11347d2cfe85b7051b11966c
Content-Type: text/plain; charset=UTF-8

I'm also in favor of restructuring the Client. Some of this work has
already been undergone in this pull request:
https://github.com/apache/flink/pull/858

It would be great if we could sync such that we do the restructuring once
the pull request has been merged. We can probably get it in next week.

On Fri, Jul 17, 2015 at 1:52 PM, Aljoscha Krettek <aljoscha@apache.org>
wrote:

> +1
> Very good idea
>
>
> On Thu, 16 Jul 2015 at 17:57 Fabian Hueske <fhueske@gmail.com> wrote:
>
> > 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 <trohrmann@apache.org>:
> >
> > > 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 <
> > > mjsax@informatik.hu-berlin.de> 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
> > > >
> > > >
> > >
> >
>

--001a11347d2cfe85b7051b11966c--