Hi Biao,
Thanks for your reply.
For the "burden" part, inside PackagedProgram and ClusterClient
we currently contains branches handling whether the mainClass of
user job jar is subclass of Program. Any effort under client api
enhancement should be compatible with such codepaths unless we
drop it.
The class Program is only active in batch codepath, while the
so-called interactive mode, i.e., executing the main method of
user's main class, is using widely and valid in both batch and
streaming codepath.
Previously we have drop flink-storm directly and I'm afraid this
Program class is much less known and used than flink-storm.
Keeping compatible with such class is an unnecessary overhead.
However, the enhancement of client api is still under discussion
so it would be ok to deprecate at first and propose removal when
necessary.
Either drop it or deprecate it prevents users from being confused
how to use this stale class. But given the community has dropped
stale flink-storm, flink-libarary/python|ml, I'd like to propose
drop this class if in the survey we receiving no usage report.
Best,
tison.
Flavio Pompermaier <pomperma...@okkam.it> 于2019年7月19日周五 下午4:21写道：
> In my experience a basic "official" (but optional) program description
> would be very useful indeed (in order to ease the integration with other
> frameworks).
>
> Of course it should be extended and integrated with the REST services and
> the Web UI (when defined) in order to be useful..
> It ease to show to the user what a job does and which parameters it
> requires (optional or mandatory) and with a proper help description.
> Indeed, when we write a Flink job we implement the following interface:
>
> public interface FlinkJob {
> String getDescription();
> List<FlinkJobParameter> getParameters();
> boolean isStreamingOrBatch();
> }
>
> public class ClusterJobParameter {
>
> private String paramName;
> private String paramType = "string";
> private String paramDesc;
> private String paramDefaultValue;
> private Set<String> choices;
> private boolean mandatory;
> }
>
> This really helps to launch a Flink job by a frontend (if the rest services
> returns back those infos).
>
> Best,
> Flavio
>
> On Fri, Jul 19, 2019 at 9:57 AM Biao Liu <mmyy1...@gmail.com> wrote:
>
> > Hi Zili,
> >
> > Thank you for bring us this discussion.
> >
> > My gut feeling is +1 for dropping it.
> > Usually it costs some time to deprecate a public (actually it's
> > `PublicEvolving`) API. Ideally it should be marked as `Deprecated` first.
> > Then it might be abandoned it in some later version.
> >
> > I'm not sure how big the burden is to make it compatible with the
> enhanced
> > client API. If it's a critical blocker, I support dropping it radically
> in
> > 1.10. Of course a survey is necessary. And the result of survey is
> > acceptable.
> >
> >
> >
> > Zili Chen <wander4...@gmail.com> 于2019年7月19日周五 下午1:44写道：
> >
> > > Hi devs,
> > >
> > > Participating the thread "Flink client api enhancement"[1], I just
> notice
> > > that inside submission codepath of Flink we always has a branch dealing
> > > with the case that main class of user program is a subclass of
> > > o.a.f.api.common.Program, which is defined as
> > >
> > > @PublicEvolving
> > > public interface Program {
> > > Plan getPhan(String... args);
> > > }
> > >
> > > This class, as user-facing interface, asks user to implement #getPlan
> > > which return a almost Flink internal class. FLINK-10862[2] pointed out
> > > this confusion.
> > >
> > > Since our codebase contains quite a bit code handling this stale class,
> > > and also it obstructs the effort enhancing Flink cilent api,
> > > I'd like to propose dropping it. Or we can start a survey on user list
> > > to see if there is any user depending on this class.
> > >
> > > best,
> > > tison.
> > >
> > > [1]
> > >
> > >
> >
> https://lists.apache.org/thread.html/ce99cba4a10b9dc40eb729d39910f315ae41d80ec74f09a356c73938@%3Cdev.flink.apache.org%3E
> > > [2] https://issues.apache.org/jira/browse/FLINK-10862
> > >
> >
>
