-
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
Sequential replies: a single request can have multiple responses #83
Conversation
…inate the sequence
…ames some functions
@amomchilov Will leave this up for at least a couple days before merging if you'd like to review it beforehand. |
Decoding issue was that errors thrown by the initializer of a decodable type weren't being wrapped in a decoding error.
Heyo, sorry for going dark, I was out on vacay. This is pretty complex stuff, I'll dig into it! I'll let you know if I have any questions/thoughts! |
No worries! There was a follow up PR after this one that did a bit of cleanup and ensures a transaction is held open, so probably best to look at both (or maybe together? I'm no git expert). |
This introduces the ability for a client to make a request that the server can respond to arbitrarily many times. It's exposed as either as an
AsyncThrowingStream
or for closure-based callbacks uses a customSequentialResult
type. This allows a server to essentially stream data to a client and should avoid needing a client to do any sort of polling.Under the hood the server is now able to make calls to the client which aren't actually XPC replies, but this is intentionally not directly exposed to SecureXPC API users. This limits the conceptual complexity of the framework (e.g. no registration of routes with the client which the server would then send to) while still allowing most bidirectional scenarios.
A few tests were added to ensure the most common scenarios work as expected, but I'm intending to add some more before merging this,