| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
| |
This lets us do much less in our rpc_invoke_fn functions.
|
| |
|
|
|
| |
Now `Method` has an Output and Update associated type, and
`decl_method` can do a little more.
|
| |
|
|
|
| |
Previously we have two places where we had to do "make a `Drain` sink
if updates aren't wanted"; now there's only one.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously the main loop received updates via a `mpsc::channel`, and
final responses via a `futures::unordered`. This could lead to
final responses being transmitted to the user before the updates
were all flushed.
Now all of the responses are sent to the main loop via the same channel,
and they can't get out-of-sequence.
Closes #817 and (IMO) simplifies the code a bit.
|
| |
|
|
|
| |
Now the update sink is its own boxed object. It is not yet passed
to the invoke functions that want it.
|
| |
|
|
|
|
|
| |
Now instead of hoping that buggy clients will detect a magic `id`,
we can simply tell them that they will get no `id` at all. If they
can't handle that case, no major harm is done: the connection will
get closed anyway.
|
| |
|
|
|
|
| |
Since we're serializing everything in this format, let's enforce it.
With this change, we can no longer cram arbitrary junk into an
RPC error, so we have to clean up our handling of cancelled requests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit big, but it's not that _complicated_.
The idea here is that we use serde's "untagged" enum facility
when parsing our `Request`s, such that if parsing as a `Request`
fails, we parse as an `InvalidRequest` and try to report
what the problem was exactly.
This lets us determine the ID of a request (if it had one),
so we can report that ID in our error message. We can also
recover from a much broader variety of errors.
We now also conform with the spec reporting errors about
completely wrong json, requests without IDs, and so on.
|
| |
|
|
|
|
| |
Even though json-rpc uses "result" to mean "a successful return value
from a method", we can't: Rust's `Result` type is so pervasive
that confusion would be inevitable.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
(Except for one case where we are using crate::Context and
task::Context at the same time.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Per our design, every connection starts out unauthenticated, and
needs one authenticate command to become authenticated.
Right now the only authentication type is "This is a unix named
socket where everybody who can connect has permission."
|
| | |
|
| | |
|
| |
|
