Thanks for your attentions!
Thank Kostas for creating the JIRA and drafting the FLIP.
I would volunteer to help review it :-)
It's good to see that we make progress on this thread.
Best,
tison.
Kostas Kloudas 于2019年8月14日周三 下午6:39写道：
> I already opened a JIRA for the removal and I will also c
I already opened a JIRA for the removal and I will also create a (short)
FLIP, as it is a PublicEvolving interface and its removal should go through
a FLIP.
The JIRA can be found here https://issues.apache.org/jira/browse/FLINK-13713
Cheers,
Kostas
On Wed, Aug 14, 2019 at 12:13 PM Stephan Ewen
+1 to drop it.
It's one of the oldest pieces of legacy.
On Wed, Aug 14, 2019 at 12:07 PM Aljoscha Krettek
wrote:
> Hi,
>
> I would be in favour of removing Program (and the code paths that support
> it) for Flink 1.10. Most users of Flink don’t actually know it exists and
> it is only making ou
Hi,
I would be in favour of removing Program (and the code paths that support it)
for Flink 1.10. Most users of Flink don’t actually know it exists and it is
only making our code more complicated. Going forward with the new Client API
discussions will be a lot easier without it as well.
Best,
Hi all,
It is nice to have this discussion.
I am totally up for removing the unused Program interface, as this will
simplify a lot of other code paths in the ClusterClient and elsewhere.
Also about the easier integration of Flink with other frameworks, there
is another discussion in the mailing
Hi,
With a one-week survey in user list[1], nobody expect Flavio and Jeff
participant the thread.
Flavio shared his experience with a revised Program like interface.
This could be regraded as downstream integration and in client api
enhancements document we propose rich interface for this integra
Hi,
I created a thread for survey in user list[1]. Please take participate in
if interested.
Best,
tison.
[1]
https://lists.apache.org/thread.html/37445e43729cf7eaeb0aa09133d3980b62f891c5ee69d2c3c3e76ab5@%3Cuser.flink.apache.org%3E
Flavio Pompermaier 于2019年7月19日周五 下午5:18写道：
> +1 to remove di
+1 to remove directly the Program class (I think nobody use it and it's not
supported at all by REST services and UI).
Moreover it requires a lot of transitive dependencies while it should be a
very simple thing..
+1 to add this discussion to "Flink client api enhancement"
On Fri, Jul 19, 2019 at
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
To Flavio, good point for the integration suggestion.
I think it should be considered in the "Flink client api enhancement"
discussion. But the outdated API should be deprecated somehow.
Flavio Pompermaier 于2019年7月19日周五 下午4:21写道：
> In my experience a basic "official" (but optional) program desc
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.
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 t
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 b
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
14 matches
Mail list logo
