Emit events on blocking operations

[EligiusSantori]

Please propagate DuplexStreamInterface::on('data') as normal event not just a promise.
Promises are only fit when you need to do a single call.
When you need a BLPOP/XREAD/XREADGROUP-based endless reading loop, event is a must have.
I think you can use command name as an event name so user will be able to choose what to handle.

[clue]

@EligiusSantori Welcome to this library! If I understand your problem correctly, then there should be no need for any additional events. Each Redis command follows request-response semantics as described in https://github.com/clue/reactphp-redis#commands.

This means that either of your commands has to be used in a loop (or using async callbacks) and each invocation returns exactly one piece of data (or a null marker if empty), see also #95 and #102 for some pointers. I've built a number of queuing systems and event brokers for commercial projects using this approach and don't see anything that's missing here at the moment. If this sounds like you, you can always shoot me an email to discuss possible support options.

I hope this helps! 👍 If so, consider supporting this project, for example by becoming a sponsor ❤️

[EligiusSantori]

Do you absolutely sure that interpreter optimizes recursion over promises there? There is 3 ways to implement it and none of them is robust enough.

1. Recursive promises as you said. Requires faith that PHP won't create a frame in call stack every iteration in complex code.
2. Async/await loop in endless futureTick() handler. But futureTick() is not intended for such tasks so there is no garantee that it won't be cleared/overwritten by some reason / in some ReactPHP version.
3. Lame way through addPeriodicTimer().

Anyway, emitting data event is not enough there because errors should be handled too. I decided to make my own implementation of Redis client dedicated for streams which is based on StreamingClient class.

[clue]

Don't get me wrong, we can definitely theorize hypothetical problems all day. You seem to imply there's some kind of potential problem with the existing approach or some future potential development, perhaps you can help me understand what problem you're seeing exactly?

You can already use await($redis->callAsync(…)) today, plus $redis->call(…) in the future (#166). In either case, I don't see any of the problems you're describing.

If you want to learn more about the roadmap for future ReactPHP v3, you may want to check out https://github.com/orgs/reactphp/discussions/481.