Hi Flavio,
Thanks for your reply and share.
I agree with that an "official" program description
would be helpful as you described.
However, this thread mainly focuses on drop the stale
class Program.
For proposing a better program description from Flink
side, feel free to start a new thread on dev or user
list(I would regard this as a user requirement).
Best,
tison.
Zili Chen <wander4...@gmail.com> 于2019年7月19日周五 下午5:10写道：
> 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
>> > >
>> >
>>
>
