I'm concerned both about the abbreviation and full name.
a) It's not distinguishing enough from existing APIs, specifically the
Streaming API, which already features stateful functions.
b) It doesn't describe use-cases that the existing APIs cannot satisfy.
On 11/11/2019 15:28, Stephan Ewen wrote:
Thanks, all for the discussion!
About the name:
- Like Igal mentioned, the name "Stateful Functions" and the abbreviation
"statefun" underwent some iterations and testing with a small sample of
developers from a few companies.
If anyone has an amazing suggestion for another name, please share.
Would be great to also test it with a small sample of developers from a few
companies, just to make sure we have at least a bit of outside feedback.
- fun vs. fn vs. func: I think these are more or less equivalent, there
are examples of each one in some language. Working with the code over the
last months, we found "statefun" to be somehow appealing.
Maybe as a datapoint, Beam uses "DoFn" but pronounces it "doo-fun". So,
why not go with "fun" directly?
About mailing lists:
- There are pros and cons for separating the mailing lists or not to do
that.
- Having the same mailing lists gives synergies around questions for
operating the system.
- Having the same mailing lists can create confusion. For example,
statefun uses a simpler, more restrictive, easier to understand
serialization scheme. Answers coming from serialization in Flink core can
easily be confusing there.
- Having the same mailing lists can be overwhelming for developers that
are new and only interested in that particular angle.
- Having a different dev mailing list makes only sense if we use a
different Jira project, because FLINK-XXXXX issue creation is linked to the
mailing list.
=> I think it is fine to start with the same mailing list and observe
first. If we find it problematic, we can separate the mailing lists.
About the repository name:
- The project is still called "Stateful Functions", but it is a mouth
full, so it would be nice to have something more concise for the repo name,
hence the suggestion for "statefun".
- @Chesnay - Are you concerned about the project name (Stateful
Functions) or the abbreviation (statefun) ?
Best,
Stephan
On Mon, Nov 11, 2019 at 6:21 AM tison <wander4...@gmail.com> wrote:
I second Chesnay's opinions, which I'd like to pick up is that I highly
recommend
reuse existing mailing lists. We can always build a separated list when the
specific
community grows, but it is hard to do it in the contract direction.
I don't stick to the name but vote my coin to "statefun". Playing with
statefun will be
fun, I think :-) (Generally, Erlang uses "fun", Go uses "func" and Rust
uses "fn", I
don't find a strong reason that "func" is an objective better choice
Best,
tison.
Xuefu Z <usxu...@gmail.com> 于2019年11月9日周六 上午4:16写道：
Regarding the package name, etc:
statefun certainly sounds more interesting, but it's confusing in my
opinion and doesn't reflect its true nature. A letter "c" at the end may
helps as "func" is more used as a short for "function" in CS.
Thanks,
Xuefu
On Fri, Nov 8, 2019 at 3:52 AM Igal Shilman <i...@ververica.com> wrote:
Hi Chesnay,
The correct link for [1] is:
http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/%3CCANC1h_vicBWQSGws6Q%2BTXJXde0K%2BAMoVN4VqGU_Hykb1N7J8ng%40mail.gmail.com%3E
1) There is no relevant post, this is the name that is currently used
both
for the website and internally.
The name is not the original name, and it evolved out of internal
discussions and a/b-testing with few early users, this name
was able to "position" the project at the correct place better than
others.
If more people would feel unconvinced, or you would strongly oppose to
it,
then we can create a separate discussion thread.
4) Ok, I will change the proposal to option (b).
Kind regards,
Igal.
On Thu, Nov 7, 2019 at 5:29 PM Chesnay Schepler <ches...@apache.org>
wrote:
[1] Does not directly link to the voting thread.
1) I skimmed all 3 threads about the stateful functions proposal and
could not find a rational for the repository name, I'd appreciate a
direct link to the relevant post.
2.1) +1 as we use o.a.f also for flink-shaded
3) +1 as it follows the existing package conventions for libraries.
4) b; I see no reason why we would isolate mailing lists when we
haven't
done so for the myriad of other components that are largely
independent
from each other (like SQL).
There are some practical issues here with having a separate dev ML,
for
example where to send FLIPs or release threads and ensuring they
reach
a
large enough audience, which a dedicated ML would likely hinder.
I'm currently also assuming that builds/commits also go to the
general
flink MLs, making it even weirder if just dev were spliced out.
5) separate component, like "API / Statefun"
Personally I'm not sold on the "statefun" name, has this been a
discussion item in one of the other threads?
On 07/11/2019 17:10, Igal Shilman wrote:
Hello everyone!
Following the successful vote to accept Stateful Functions into
Flink
[1],
I would like to start a discussion regarding the technical aspects
of
the
contribution.
Once the discussion will finalize I will summarize the results
into a
FLIP
and bring it up to a vote.
1) External repository name - Following the discussion conclusion
of
[2]
we
need a name for an external repository.
proposal: flink-statefun
rational: discussed in the other thread.
2) Maven modules proposal:
2.1) group id: org.apache.flink
2.2) artifact ids: replace "stateful-functions-*" with
"statefun-*".
3) Java package name: org.apache.flink.statefun.*
4) Mailing list - should we reuse the existing mailing list or
have a
dedicated mailing list for stateful functions?
options:
a) Completely separate mailing list for statefun developers and
users (
dev-state...@flink.apache.org and user-state...@flink.apache.org)
b) Reuse the dev and user mailing lists of Flink
c) Reuse Flink's user mailing list, but create a dedicated mailing
list
for
development.
d) Have a separate single list for developers and users of
statefun (
state...@flink.apache.org)
proposal: (c) separate dev list: "dev-state...@flink.apache.org"
and
reuse
the Flink user mailing list.
rational: It is very likely that stateful functions users would
encounter
the same operational issues as regular Flink users, therefore
it might be beneficial to reuse the Flink user list.
5) separate JIRA project or just component / tag?
proposal: use separate component for statefun.
Thanks,
Igal
[1]
http://mail-archives.apache.org/mod_mbox/flink-dev/201911.mbox/browser
[2]
http://mail-archives.apache.org/mod_mbox/flink-dev/201910.mbox/%3CCANC1h_vRPWs1PnRPuDe602zhX=3j713fanz0wn2dw9pzf_t...@mail.gmail.com%3E
--
Xuefu Zhang
"In Honey We Trust!"
