Replies: 18 comments 47 replies
-
|
I would be pleased to have a proper update of https://github.com/ratchetphp/ that is a "side project" of ReactPHP but that would need some love. There is some very interesting PR (including that one ratchetphp/Ratchet#851) that are ready to be reviewed and merged and that would greatly help projects built on it. Thanks for everything! <3 |
Beta Was this translation helpful? Give feedback.
-
|
Agree that we want to support others projects to have a smooth upgrade path! Also agree that Ratchet is definitely one of the bigger and more important projects that use ReactPHP. We can't promise to have the entire ecosystem upgraded in time for the release, but there's definitely hope somebody will pick this up, considering the upgrade path shouldn't be too hard! |
Beta Was this translation helpful? Give feedback.
-
|
My primary usecase for ReactPHP is websockets via Ratchet, so I would love to see some work being done in that space as well. |
Beta Was this translation helpful? Give feedback.
-
|
If breaking changes are to be expected, let's take the opportunity to drop unsupported PHP versions. This would allow us to modernize the codebase (think typings) and more easily introduce tools such as PHPStan. |
Beta Was this translation helpful? Give feedback.
-
|
I think we agree that we want to get rid of "old" PHP versions.
Going for PHP 8.1+ now would mean we would exclude most of our existing installation base. Going for PHP 7.1+ removes most of the pain points (from a maintainer's perspective) that we want to address in I've already made the point that I would like to call the next version I agree that we want to have PHP 8.1+ at some point in the future, especially when considering a potential |
Beta Was this translation helpful? Give feedback.
-
|
I don't get the obsession with supporting dead php versions though. Realistically any current code base is not running on PHP7.1. If an existing installation is running then it's not likely that they'll update to vNext anyway. When breaking BC, it makes sense to do it in a big way, I'd even push for dropping anything below 8.1. Note that any project can simply choose not to upgrade to the latest version, if they've been happily not upgrading their PHP version for 10 years I don't see why they should have a problem not upgrading ReactPHP to the latest and greatest. |
Beta Was this translation helpful? Give feedback.
-
|
@SamMousa We have a whole lot of legacy code making it currently run on PHP 5.3. Upgrading all of that to PHP 7.1 would be amazing already for us maintainers and contributors compared to having to deal with PHP 5.3. I'm not saying it's perfect, but there is more to it than just going to the latest and greatest. Something also to consider is that going to PHP 7.1 is easier for a v3 with some breaking, than it is to go PHP 8.1 with big breaking changes because we most likely will make our API's use fibers. PHP 8.1 is where we want to go, it might even land within a year after v3. |
Beta Was this translation helpful? Give feedback.
-
|
I think that https://packagist.org/packages/react/event-loop/php-stats#1.3 can be used as a good indicator, btw. Around 90% of the users are running PHP 7.4+. If you're aiming to bring more people along, it's understandable to look at PHP 7.1. I think the main concern I sense is not about which PHP version will be used but the pace of modernisation... In other words, what's the general expectation for getting to "the place where we want to be"? And more specifically, how does the community can help achieving that? The latter is much more important IMHO, because from a user perspective nobody should care which min PHP version is supported as long as the project runs smoothly on the the latest ones... |
Beta Was this translation helpful? Give feedback.
-
Good input and agree that this is perhaps the most important message: ReactPHP always aims to support the latest PHP versions as soon as possible, so at the time of writing this we already support PHP 8.2 (scheduled to be released next month).
As per my suggestion in https://github.com/orgs/reactphp/discussions/472#discussioncomment-3680968 I think v3 will be major improvement from a maintenance perspective as it will get rid of a bunch of legacy hacks. Yes, it may not use all newest language features, but as a maintainer of ReactPHP, I don't see anything that would be a major issue right now or the foreseeable future. A future v4 that would bump this up to PHP 8.1+ is already on the roadmap as the next major version after v3. This will allow us to take advantage of all newest language features consistently across the ReactPHP ecosystem. I very much prefer this smooth upgrade path over a major bump that would potentially leave many consumers behind. |
Beta Was this translation helpful? Give feedback.
-
|
Production-ready Filesystem Component :) |
Beta Was this translation helpful? Give feedback.
-
|
Something akin to Flysytem, but async, would be awesome. |
Beta Was this translation helpful? Give feedback.
-
|
Agree that a major overhaul for the filesystem component would be a fantastic addition and is definitely part of the bigger picture! I'm sure this is something we will see at some point in the future, but personally I'd rather consider this to be independent of vNEXT to make sure one doesn't block the other. There's hope the filesystem component would be easier to work on once vNEXT is released, considering some of the planned features to come! |
Beta Was this translation helpful? Give feedback.
-
That is the plan ;) |
Beta Was this translation helpful? Give feedback.
-
Sorry, let me rephrase that, the current 0.2 branch is already a ton easier to work on than 0.2. vNEXT will hopefully make it even easier to work with. |
Beta Was this translation helpful? Give feedback.
-
|
Just marked reactphp/filesystem#112 ready for review. This will help stabilize that component as it can use two different extensions for I/O. |
Beta Was this translation helpful? Give feedback.
-
|
I suggest the next version should consistently be called ReactPHP v3. This would mean that for most components, we would jump straight from ReactPHP v1 to v3 and would skip v2 for most components. While this may seem odd at first, I think this makes sense for the following reasons. First of all, ReactPHP consists of individual components, most of which are currently at v1.x.y, while some components already have a v3 or v4 scheduled or released. In particular, our Async component has been released as version v2+v3+v4 simultaneously to accommodate different PHP versions. For our Promise component we currently support a v1+v2 with plans for an upcoming v3. If we release a v3 for all components that are currently at v1, we can be more consistent and make it easier to understand for consumers. In particular, this means consumers do not have to figure out if v2 of X is compatible with v3 of Y. Instead, we can consistent refer to this as ReactPHP v3 and ensure that everything v3 is compatible with each other. A minor downside is that skipping v2 might seem confusing ("What happened to v2?"). I don't think this is a particularly compelling argument, the main aspect here is that v3 >> v1. From a SemVer perspective, skipping a major version is also completely fine. Also, do you remember PHP 6? On a related note, both Promise v3 and Async v3 have the same minimum PHP requirements (PHP 7.1+). Async v4 requires PHP 8.1+. We could apply the same logic to our other components to be more consistent, but see also thread above for more discussions about PHP version requirements (https://github.com/orgs/reactphp/discussions/472#discussioncomment-3645588). TL;DR: v3 >> v2 |
Beta Was this translation helpful? Give feedback.
-
|
Late in the discussion. Have you considered using monorepo for all packages? This can ease contribution and cross-component updates. That requires some tooling that already exists to split the monorepo in sub repositories. |
Beta Was this translation helpful? Give feedback.
-
|
@GromNaN This was actually once the case for ReactPHP, so this is definitely worth discussing. I think it is a good idea to open up a separate discussion for this, could be a longer one and I'm not sure if this here is the right place. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
I suggest the next version should receive long-term support (LTS) for at least 2 years. I think one of the unique selling points of ReactPHP has always been the fact that it is very stable and predictable. We've started releasing v1 of our core components on 2018-07-11 and have a track record of not introducing any unexpected BC breaks. The next version will include a number of BC breaks as discussed in other threads above and we will include clear upgrade guides for anybody coming from a prior version. Once this is released, I would like to stress that we do not plan any immediate BC breaks for a reasonable time frame. As such, consumers will be able to rely on our APIs for their projects also longer-term. As per the discussion above, I would suggest we should name the next version v3 (https://github.com/orgs/reactphp/discussions/472#discussioncomment-3680968) and should support v3 for at least 2 years. v3 should be supported at least until a future v4 is released, plus a time frame of ~6 months to ensure a smooth upgrade again. (A future v4 is not something that would be on the immediate roadmap for at least 12 months, but I wouldn't want to preclude any future work on this version. Should we release v4 sooner, we should continue supporting v3 at least for 2 years as suggested above.) |
Beta Was this translation helpful? Give feedback.
-
|
Once the next version is released, we should mark v1 end of life (EOL) after a reasonable transition period of ~6 months. The next version is going to be the way forward for ReactPHP. v1 may see some smaller adjustments / fixes in the future, but all development efforts and new features will focus on the next major instead. To ensure a smooth upgrade path, we should continue providing support for v1 for a reasonable transition period of ~6 months. We're open to learn more about how much demand there is to continue supporting v1. If your project or company requires longer-term support for EOL versions, please reach out and we may be able to work this out on a case-by-case basis. |
Beta Was this translation helpful? Give feedback.
-
|
As one of the main features for vNEXT, I would like to see blocking APIs that work just like traditional, idiomatic PHP code. In a gist, I would like to be able to do this (vNEXT) try {
$response = $http->get('http://www.google.com/');
var_dump($response->getHeaders(), (string)$response->getBody());
} catch (Exception $e) {
echo 'Error: ' . $e->getMessage() . PHP_EOL;
}instead of this (v1): $http->get('http://www.google.com/')->then(function (Psr\Http\Message\ResponseInterface $response) {
var_dump($response->getHeaders(), (string)$response->getBody());
}, function (Exception $e) {
echo 'Error: ' . $e->getMessage() . PHP_EOL;
});ReactPHP v1 has always been about "making hard things possible", that's why we've focused on async APIs like the latter example. In the future, I would like to also focus on "making easy things easy" and provide simple(r) APIs like the former example. In my opinion, one does not exclude the other. Thanks to fibers available as of PHP 8.1+, we can create APIs that can be used in an async context and yet look like normal, blocking APIs. The Instead of deciding for either fiber-based APIs or promised-based APIs, I would argue that there's value in both styles, depending on how they're used. For this reason, I would suggest we simply add methods that do to cover both cases like this: class HttpClient
{
public function get(string $url): ResponseInterface;
public function getAsync(string $url): PromiseInterface<ResponseInterface>;
// …
}This allows us to provide type-safe APIs and has the benefit that no mapping using TL;DR: Make easy things easy and hard things possible. |
Beta Was this translation helpful? Give feedback.
-
|
How about we use the current default loop as the only eventloop in ReactPHP. There's currently the possibility to pass in an event loop instance for most functions across all ReactPHP components. A year ago the default loop was added which triggers if there's no explicit loop given. The following example comes from reactphp/http#410: // old (still supported)
$browser = new React\Http\Browser($loop);
$server = new React\Http\Server($loop, $handler);
// new (using default loop)
$browser = new React\Http\Browser();
$server = new React\Http\Server($handler);I'm curious, are there any cases where you want to use a different eventloop? Maybe it could be a new feature to always use the default loop and get rid of the optional The documentation for the default loop in all components also says the following about the use of an external eventloop:
So it seems for most cases you don't even want/need a specific loop, so why not remove this option completely? |
Beta Was this translation helpful? Give feedback.
-
|
The main benefit IMHO is testability. Having the constructor parameter allows users to provide a loop for tests without managing global state. I'd really appreciate if we could keep it. |
Beta Was this translation helpful? Give feedback.
-
|
I meant keeping the ability, not necessarily the current implementation. 😁 |
Beta Was this translation helpful? Give feedback.
-
|
@lcobucci I agree, we don't need to get completely rid of the ability to use a different loop, sounds like we need an additional way to achieve this if there isn't one already 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
Right now, This ties in with the PHP version requirements discussed above in https://github.com/orgs/reactphp/discussions/472#discussioncomment-3645588, the most important PHP versions for this would be:
|
Beta Was this translation helpful? Give feedback.
-
|
What about creating an emoticon legend so people can reply using emotes as a cheap "voting" mechanism? It'll give some insight on what contributors prefer. |
Beta Was this translation helpful? Give feedback.
-
|
@SamMousa Do you feel there's anything that needs to be added beyond a 👍/👎? This discussion is mostly aimed at bringing up potential wish list ideas and to gauge interest, we may or may not apply ideas for the upcoming version depending on a number of factors (feedback, demand, priorities). |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see built-in support for PSR-15 (HTTP Server Request Handlers). This is currently possible through https://github.com/friends-of-reactphp/http-middleware-psr15-adapter, but I would love to see if we can build this into the HTTP component to make reusing middleware and request handlers even easier. Full support will likely require fibers (PHP 8.1+), but PHP version requirements are discussed above in https://github.com/orgs/reactphp/discussions/472#discussioncomment-3645588. We might be able to come up with a way to provide limited support on prior PHP versions as per https://framework-x.org/docs/async/fibers/#requirements or we could also provide support only for matching PHP versions. Also refs wish list regarding v3 <-> v4 discussed above in https://github.com/orgs/reactphp/discussions/472#discussioncomment-3680968. |
Beta Was this translation helpful? Give feedback.
-
|
I'd dabbled with this and full support requires fibers. We can support it in v3 but error on when it doesn't run on PHP 8.1, which isn't something I see work with our aim to run rock solid everywhere we support the PHP version for. |
Beta Was this translation helpful? Give feedback.
-
|
Agree that full support will likely require fibers (PHP 8.1+), but there's definitely room for some partial feature implementations (possibly only as a future preparation). Specifically brought this up as a "wish list idea", we'll see if this has to wait for a future v4 or if we can provide some support for this in v3 already. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to see built-in support for PSR-18 (HTTP Client) and potentially PSR-17 (HTTP Factories). We will likely see more blocking APIs in the next version as discussed above in https://github.com/orgs/reactphp/discussions/472#discussioncomment-3715488. Once these APIs are in place, it will be straight forward to add support for the |
Beta Was this translation helpful? Give feedback.
-
|
Would love to see this happen, especially PSR-18! apart from getting rid of 'old php' it would be very straight forward. |
Beta Was this translation helpful? Give feedback.
-
|
We may want to add support for PSR-16 (Common Interface for Caching Libraries). We will likely see more blocking APIs in the next version as discussed above in https://github.com/orgs/reactphp/discussions/472#discussioncomment-3715488. Once these APIs are in place, it will be relatively straight forward to add support for the API defined by PSR-16, especially considering the APIs of our async Cache component are heavily influenced by PSR-16. This is currently possible through https://github.com/WyriHaximus/reactphp-cache-psr-16-adapter, but I wonder if we can build this into the Cache and/or DNS component to simplify reuse. |
Beta Was this translation helpful? Give feedback.
-
|
Oh yes please, I've created https://github.com/WyriHaximus/reactphp-cache-psr-16-adapter in less than an hour. We could provide an adapter directly from |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see better error and exception handling for ReactPHP. In particular, all errors should be shown by default unless explicitly hidden. Most notably, this affects promises (as discussed in reactphp/promise#87): $promise->then(function () {
throw new \RuntimeException('I should be shown');
});Likewise, we may want to reconsider what happens if streams and sockets report an $stream = new ThroughStream(function () {
throw new \RuntimeException('Where should I be shown?');
});
$stream->write('Hello!');On top of this, we may want to reconsider what is supposed to happen if an event handler or timer throws an exception: Loop::addTimer(1.0, function () {
throw new \RuntimeException('Where should I be shown?');
});
$stream->on('data', function () {
throw new \RuntimeException('Where should I be shown?');
});
$socket->on('connection', function () {
throw new \RuntimeException('Where should I be shown?');
});We may want to emit an $stream = new ThroughStream(function () {
throw new \RuntimeException('I should be shown');
});
$stream->on('error', function () {
throw new \RuntimeException('But where should I be shown?');
});
$stream->write('Hello!'); |
Beta Was this translation helpful? Give feedback.
-
|
Possibility to trace timers/signals/streams to where they have been added from. When we are in situations where these accumulate for whatever reasons we have no way to know where they come from (i.e. code that does not clean up properly). |
Beta Was this translation helpful? Give feedback.
-
|
Not sure how this would fit on the roadmap, but it looks like this should already be possible by using a loop decorator like https://github.com/WyriHaximus/reactphp-event-loop-inspector, so let's also ping @WyriHaximus 👍 |
Beta Was this translation helpful? Give feedback.
-
|
@clue Thanks for letting me know I didn't mark that package as deprecated and to use https://packagist.org/packages/react-inspector/event-loop instead. That said, it is something we can consider but always as an opt-in due to performance impacts. @fritz-gerneth I'm all in on support for this, either through "3rd" party packages like I'm doing with react-inspector, or build-in.
Using a PSR-14 dispatcher in my apps for that, and when it triggers they will gracefully shut down connections and such clearing out the loop letting it stop on it's own. |
Beta Was this translation helpful? Give feedback.
-
|
Metric(s) for Loop time utilization. I.e. to create monitors how much idle / busy time a loop has. Thinking about what |
Beta Was this translation helpful? Give feedback.
-
|
there are 3 metrics possible:
|
Beta Was this translation helpful? Give feedback.
-
|
@determin1st thanks for your input 👍 Overall, I see the benefits in this, but I'm not sure how much is needed to be ready for the upcoming ReactPHP v3 and I agree with @clue that it will be interesting to make this work. In my opinion, this shouldn't postpone the release of v3 as we can still take a look at this once v3 is released. If we have some good arguments that this feature is necessary for the release of the upcoming major version, I'm happy to give this some further investigation. FYI: We also released our roadmap to reactphp/eventloop v3 containing our current plans & feature additions for the next major version of the EventLoop component. |
Beta Was this translation helpful? Give feedback.
-
|
@SimonFrings ye, sure, thats the property of event loop.. then I would suggest to unite the event loop and the promise projects as they dont make any sense without each other. more entry points doesn't mean more possibilities. the Promise as it was presented by Promises/A spec historically was a compilation of already running/implemented variants, those designs today are out-of-date to my taste, i would completely re-design some parts of it. |
Beta Was this translation helpful? Give feedback.
-
|
@determin1st I can understand where you're coming from, but a complete redesign would be way too much for the upcoming major release. In my opinion, I think it's good that the Promise and the EventLoop components exist as separate projects. This way, when creating your own APIs, you have the choice to select and integrate only the components that are necessary for your specific requirements. Like already mentioned above, we can hold a separate discussion about this topic and how an implementation could look like, but I don't think this will make the cut for the upcoming ReactPHP v3 release. |
Beta Was this translation helpful? Give feedback.
-
|
a user of the Promise does not manipulate Loop object or constructs new kind of Promise upon a point of asynchronity. user combines Promises, builds Promise chains and finally, user somehow puts Promises into the Loop for execution. this is |
Beta Was this translation helpful? Give feedback.
-
|
PHPStan support for promises, i.e. check types through resolved/rejected values and callback arguments. |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely! PHPStan support is already being discussed in #469 and it looks like this will be much easier and more complete in the future thanks PHP upgrades and stricter types discussed above in https://github.com/orgs/reactphp/discussions/472#discussioncomment-3645588, https://github.com/orgs/reactphp/discussions/472#discussioncomment-3715488 and https://github.com/orgs/reactphp/discussions/472#discussioncomment-3851175. |
Beta Was this translation helpful? Give feedback.
-
|
We've just announced our plans for ReactPHP v3 here: https://github.com/orgs/reactphp/discussions/481 🎉 We will keep this wish list open in case there are more ideas for v3, so make sure to let us know in time for v3. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @clue is there any update on the v3 release? You were mentioning early 2023 as release target but I didn't find any updates since 2022. Thx! |
Beta Was this translation helpful? Give feedback.
-
|
Hey @BernhardBaumrock, Tl;DR live got in the way but we're working hard to get v3 out the door. Currently finishing off some things for |
Beta Was this translation helpful? Give feedback.
-
|
Thx for the update @WyriHaximus great to hear! No pressure, just wanted to know if the project is still alive :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
ReactPHP
vNEXTis going to happen! 🎉We're committed to work on the next major version of ReactPHP (dubbed
vNEXTfor now). We've actually started working on this early last year but believe it's time to finally make this public and give people a chance to see what we're up to and to contribute.Before sharing too many of our own ideas, we'd like to take the opportunity to reach out to the community (that's you!). This is why we're starting this discussion in the hopes to get more people involved and share their own ideas of what a future ReactPHP could look like.
Suggest your ideas!
Bring in your ideas! Simply create a new comment thread in this discussion for each idea you want to see implemented in vNEXT (any number of ideas, ideally one idea per comment thread).
We want to focus on the big picture here, especially changes that help us shape the future of ReactPHP and may involve BC breaks and other major changes. While we appreciate pure feature ideas, this is probably not the best place to suggest things that would also be possible in a future
vNEXT.1.We plan to use this discussion also to bring in our own ideas as well in a few days, but want to give more people a chance to suggest their own ideas first. We're curious what our community wants and how our plans align!
Help us prioritize
Everybody is invited to share their ideas! Some ideas will be better, some ideas will be less obvious. Help us understand what you need most.
You can cast your voice by voting on each comment thread or leave feedback in a comment thread if suggestions need more context. If a suggestion requires more discussion space, we'll try to create a separate discussion and link from here to create a common overview.
We plan to bring in our own ideas here as well. We're equally interested in feedback for your ideas and our own ideas and plan to adjust our roadmap according to the needs of our users.
Next steps
Share ideas, leave feedback, vote. Depending on feedback, we plan to keep this open for a couple of weeks and will announce further plans early next month.
Looking forward to your ideas and feedback! ❤️
Beta Was this translation helpful? Give feedback.
All reactions