| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Per discussion, this field isn't really specified in a way that lets
us fill it sensibly at the moment. So for now, we're going to just
omit it.
Additionally, we said that we'd Report on our errors; this branch
changes the implementation of RpcError to do that.
Question: Will the blanket implementation for Into<RpcError> make
it harder to re-add a Data field later on if we want to do so?
|
| |
|
|
|
| |
It is no longer necessary to say, for every RPC method,
that its error type is RpcError.
|
| |
|
|
|
|
|
|
| |
This is needed so that we can cast special methods' return types
properly.
I wish I could make this optional, but Rust doesn't allow
defaulting an associated type.
|
| |
|
|
|
|
| |
This will allow us to create dispatchable methods that are only
invoked from inside the arti code, and are not themselves
serializable.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We don't actually need this to be a trait; we just need
methods and objects to have a `CONST_TYPE_ID_` if they want to
participate in the inventory-based method registry.
Removing this trait makes it much simpler to declare methods and
objects.
|
| |
|
|
|
|
| |
This simplifies our implementation logic in a few places,
and simplifies our invocation syntax greatly. There are a few
infelicities, noted in `TODO RPC` comments.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Right now, this lets us say whether the method was unrecognized or
whether the parameter type was incorrect.
We'll use this to enforce correct method names later on.
(I have to add another `inventory` here, since the `typetag`
maintainer does not want to expose this functionality: see
https://github.com/dtolnay/typetag/issues/57#issuecomment-1506106290
)
|
| |
|
|
|
| |
Now `Method` has an Output and Update associated type, and
`decl_method` can do a little more.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This code uses some kludges (discussed with Ian previously and
hopefully well documented here) to get a type-identifier for each
type in a const context. It then defines a macro to declare a
type-erased versions of a concrete implementation functions, and
register those implementations to be called later.
We will probably want to tweak a bunch of this code as we move ahead.
|
| |
|
|
|
| |
This crate will hold the backend pieces of RPC interaction that
different parts of Arti get to implement.
|
| |
|
