-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add TryServerStreaming interaction pattern #71
Conversation
also reorganize this into a separate pattern dir.
source: C, | ||
map: Arc<dyn MapService<S, SInner>>, | ||
pub(crate) source: C, | ||
pub(crate) map: Arc<dyn MapService<S, SInner>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Frando one idea of this crate was that you should be able to define new patterns outside the crate. For that this would have to be somehow exposed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYM by "define new patterns outside the crate"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We got 4 built in interaction patterns: rpc, server streaming, client streaming and bidi streaming. But there can be many more. The interaction patterns are not closely coupled to the server or client transport impls. So you should be able to do all of this outside the main crate. I just added these 4 so it is "batteries included" in a way.
@@ -0,0 +1,6 @@ | |||
//! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be nice to have a short description here of what exactly a pattern
is.
fa17924
to
5723d5e
Compare
also reorganize this into a separate pattern dir.
I think we need to separate out the patterns more. E.g. in some cases it would be useful if you don't have a fn that returns a stream but get a fn that gets a sink.
In any case, this is the attempt to do an interaction pattern that is more friendly to the case where the stream creation itself is async and fallible, and the stream contains results.
For usage, see the example in the try.rs test.