Support concept of "streaming" in Actor model

drub0y commented 4 years ago

Modern actor frameworks such as Orleans or Akka.NET provide a first class abstraction over external event systems in the form of "streams". Actors can then subscribe to these stream abstractions to receive events asynchronously without any knowledge of the backing event store or the mechanisms used to access it.

Given that Dapr has a pub/sub abstraction built-in already, it would seem that the implementation of Actor Streams could be tied to this same underlying abstraction very easily. Doing this would ensure a unified story for extensibility within the platform because now pub/sub component providers need only to adhere to a single specification which would then automatically light up pub/sub capabilities for both "raw" subcribers as well as actors.

amanbha commented 4 years ago

@drub0y That would be a good addition, but I believe this support would be needed from dapr runtime with pubsub support for actors.

drub0y commented 4 years ago

Would it? If you built the SDK abstraction on top of the existing pub/sub abstraction I do not see any further requirements of the underlying runtime. Is it that you would just like to have the discussion over there of whether or not building on top of the pub/sub abstraction is the right thing to do? Happy to do it, just want to make sure the issue I open there contains the correct "ask".

amanbha commented 4 years ago

Its not about the abstraction in sdk, its about getting support from the underlying runtime to support the scenarios needed. We can continue the discussion here, could you please share a more concrete proposal for the changes needed in the SDK alongwith the apis needed, then we can discuss if the existing runtime functionalities can support it.

vinayada1 commented 3 years ago

Hi....could you log a proposal under the dapr runtime repo where we need to first add the support?

dapr / dotnet-sdk

Support concept of "streaming" in Actor model #301