Interesting, because it seems the opposite to me. The example client code makes an RPC call look exactly like a regular Python call. If you believe (which I do) that the syntax of something implies semantics of that something, this would mean you are trying to tell people an RPC call is the same as a local call.
> we differentiate errors on the RPC layer
What does an error look like if my RPC call times out? What does it look like if my RPC does an RPC call that times out?
The website says: "Built-in heartbeats and timeouts detect and recover from failed requests.", what does the 'and recover' part mean?
Syntactically ZeroRPC calls look mostly the same as local calls, but semantically we don't hide erroneous states like you might expect a typically opaque RPC layer to do.
If an RPC call times out, you get a special exception that you can check against. Same with heartbeat failures.
"Recover" might be bad copy; what we mean is that ZeroRPC cleans up pending results. It is up to you to figure out what to do to fully recover. You have to develop with this in mind, but the trade-off is that failures are not hidden from you, and you have full flexibility in deciding what to do in failed states.
My point is that syntax implies semantics. c.hello(..) implies a local call and the semantics that go with it. But the semantics are actually different, which is bad.
Interesting, because it seems the opposite to me. The example client code makes an RPC call look exactly like a regular Python call. If you believe (which I do) that the syntax of something implies semantics of that something, this would mean you are trying to tell people an RPC call is the same as a local call.
> we differentiate errors on the RPC layer
What does an error look like if my RPC call times out? What does it look like if my RPC does an RPC call that times out?
The website says: "Built-in heartbeats and timeouts detect and recover from failed requests.", what does the 'and recover' part mean?