Subscriber payload or contextualize request

[victorherraiz-santander]

Have you ever consider adding payload to subscribe method on the publisher? Subscriptions move upstream and it could be useful to have something that carries data and it is visible in the API.

Another option could be to add some context to the request method in the subscription.

[jponge]

It's something that implementations can support in a ad-hoc fashion (see https://smallrye.io/smallrye-mutiny/1.7.0/guides/context-passing/ in Mutiny) but IMHO the RS APIs should not define context passing.

[victorherraiz-santander]

Several real world scenarios require non-functional data (e.g. security context). Reactive implementations are compatible but ad-hoc implementations to provide an execution context could clash, leave some important data behind or even fail to clean up properly. In my opinion, define a payload in the subscription and the semantics for moving the data upstream could help to normalise context passing and make the implementation more transparent.

[akarnokd]

Is it mutable or immutable context? How is it supposed to travel to multiple sources? Are there lifecycle considerations of the context?

I have thought about many extension direction to RS years ago but almost always I ended up building upon RS as it is.

Therefore, I suggest you prototype your ideas and implement a few non-trivial operators (flatMap, publish) to see if it works out or not.

[victorherraiz-santander]

@akarnokd @jponge thank you for your interest!

In my opinion the context should be immutable and could be decorated by operators/processors. I like how they expose context in CoreSubscriber from reactor project.

I did some prototypes years ago to understand better how reactive specs works, but I always end up using a library. You are right @akarnokd, I will try to do a PoC with some operators and try to see how it works, especially when I move between java Flow and reactive stream interfaces.