Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove SMS Provider #7475

Closed
Tracked by #7467
rafikiassumani-msft opened this issue Jan 10, 2022 · 4 comments · Fixed by #7818
Closed
Tracked by #7467

Remove SMS Provider #7475

rafikiassumani-msft opened this issue Jan 10, 2022 · 4 comments · Fixed by #7818
Assignees
Labels
area-streaming Category for Orleans streaming issues cost: S Status: Fixed
Milestone

Comments

@rafikiassumani-msft
Copy link

rafikiassumani-msft commented Jan 10, 2022

Value: SMS provider lacks decoupling capabilities needed from streams. Our goal is to make sure customers are using in-memory stream provider.

@ghost ghost added the Needs: triage 🔍 label Jan 10, 2022
@rafikiassumani-msft rafikiassumani-msft added area-streaming Category for Orleans streaming issues cost: S and removed Needs: triage 🔍 labels Jan 10, 2022
@rafikiassumani-msft rafikiassumani-msft changed the title Remove SMS Provider (Cost: S) Remove SMS Provider Jan 10, 2022
@rafikiassumani-msft rafikiassumani-msft added this to the .NET 7 Planning milestone Jan 13, 2022
@andyhoyle
Copy link

It has been mentioned that this will be implemented with the 4.0 release.

We make extensive use of the SMS provider (and fully understand the consequences of doing so) to allow direct grain communication without the need for explicitly calling the destination grain. It allows us to raise an event in the source grain and subscribe to it using implicit subscriptions in the destination grain without the source grain ever needing to know about the destination grain.

Event handlers in our grains only ever mutate state in memory and once all grains in the chain have successfully processed events, the state it is committed to storage for all grains in the chain. It is an important part of our infrastructure.

I understand the reason for removing it, but could we not keep the feature, but rename it away from the streams namespace?

@benjaminpetit
Copy link
Member

I understand that it might not be a very popular decision.

Renaming SMS from the stream namespace wouldn't be sufficient, since SMS share some code with persistent streams. This common code is limiting us in enhancing the streaming infrastructure.

Ideally, I think SMS users should move to MemoryStreams. Did you considered moving to that?

@andyhoyle
Copy link

For reference - discussed on Discord channel: https://discord.com/channels/333727978460676096/950376855297474611

@benjaminpetit
Copy link
Member

I forgot to update this thread so there is the current plan for 4.0:

  • Remove SMS from the stream provider dll, and encourage people to migrate to InMemoryStream provider
  • Create in a separate dll extension a partial replacement for SMS. It will only support "implicit" subscription, and the interface will be incompatible with the "traditional" stream interfaces.

The goal is to discourage people completely to use SMS just as another stream implementation, but allow people that want SMS-like behavior to still use it.

@ghost ghost added the Status: Fixed label Jul 6, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Aug 6, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-streaming Category for Orleans streaming issues cost: S Status: Fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants