search

apache / pekko

Build highly concurrent, distributed, and resilient message-driven applications using Java/Scala
https://pekko.apache.org/
Apache License 2.0
1.17k stars 139 forks source link

Introduce a timer source api? #253

Closed He-Pin closed 1 year ago

He-Pin commented 1 year ago

I was wanted this once https://github.com/akka/akka/issues/31705, and today after read this:

https://github.com/netty/netty/pull/13169

So I open this issue here too.

mdedetrich commented 1 year ago

I think this would be a candidate for a PIP (Pekko Improvement Proposal) which would be created at the cwiki here (see https://cwiki.apache.org/confluence/display/PEKKO/Processes, as far as I understand at least for Pekko Improvement Proposal you need to use cwiki, if not I have a personal preference for github).

The idea behind a PIP is for you to state motivations, claim, design considerations(i.e. specifically in this case do we want to add a dependency or directly implement a correct timer etc etc). Once a proposal is made then you can create a [DISCUSS] thread on the mailing list where people can talk about it, and afterwards if there are not strong objections in [DISCUSS] you can then initiate a vote which if accepted with a lazy 3 majority then you are free to implement it.

As an inspiration to PIP's, you can look at Kafka's KIP's to see the format https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals. I noticed that on our cwiki page we don't even have a section for PIP's, @pjfanning shall we get the process started/solidified?

pjfanning commented 1 year ago

I'm not sure. Until we start doing releases, it's hard to consider anything that we don't intend for the initial release. It's useful to log the requirement but I don't see much point expending a lot of discussion time about them.

Is there a resaon why this timer feature could not be a separate project that uses Pekko APIs but that exists as its own non-ASF jar? I would prefer if Pekko was extensible instead of every feature having to become part of Pekko itself.

mdedetrich commented 1 year ago

I was under the presumption that a PIP process is part and parcel of incubation process and that releases don't really play into it?

Is there a resaon why this timer feature could not be a separate project that uses Pekko APIs but that exists as its own non-ASF jar? I would prefer if Pekko was extensible instead of every feature having to become part of Pekko itself.

The intention of a PIP is to force the person to think about these considerations and come up with a proposal so that it can be discussed, no?

pjfanning commented 1 year ago

We can choose to have a PIP process but there is no requirement for an ASF project to have one.

mdedetrich commented 1 year ago

Oh I had no idea

@He-Pin In that case I would recommend making a discuss thread so we can talk about it, I think the biggest issue might be adding a dependency

He-Pin commented 1 year ago

Ok, thanks. I will open up one there.