+1 (for the same reasons I posted on the other thread)
> On 14. Aug 2019, at 15:03, Zili Chen <wander4...@gmail.com> wrote:
>
> +1
>
> It could be regarded as part of Flink client api refactor.
> Removal of stale code paths helps reason refactor.
>
> There is one thing worth attention that in this thread[1] Thomas
> suggests an interface with a method return JobGraph based on the
> fact that REST API and in per job mode actually extracts the JobGraph
> from user program and submit it instead of running user program and
> submission happens inside the program in session scenario.
>
> Such an interface would be like
>
> interface Program {
> JobGraph getJobGraph(args);
> }
>
> Anyway, the discussion above could be continued in that thread.
> Current Program is a legacy class that quite less useful than it should be.
>
> Best,
> tison.
>
> [1]
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/REST-API-JarRunHandler-More-flexibility-for-launching-jobs-td31026.html#a31168
>
>
> Stephan Ewen <se...@apache.org> 于2019年8月14日周三 下午7:50写道：
>
>> +1
>>
>> the "main" method is the overwhelming default. getting rid of "two ways to
>> do things" is a good idea.
>>
>> On Wed, Aug 14, 2019 at 1:42 PM Kostas Kloudas <kklou...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> As discussed in [1] , the Program interface seems to be outdated and
>>> there seems to be
>>> no objection to remove it.
>>>
>>> Given that this interface is PublicEvolving, its removal should pass
>>> through a FLIP and
>>> this discussion and the associated FLIP are exactly for that purpose.
>>>
>>> Please let me know what you think and if it is ok to proceed with its
>>> removal.
>>>
>>> Cheers,
>>> Kostas
>>>
>>> link to FLIP-52 :
>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=125308637
>>>
>>> [1]
>>>
>> https://lists.apache.org/x/thread.html/7ffc9936a384b891dbcf0a481d26c6d13b2125607c200577780d1e18@%3Cdev.flink.apache.org%3E
>>>
>>
