CORBA is trippier than that. A client’s request could include elements not normally serializable, like callbacks. A server could provide an object in response to your query and then continue mutating it, with the mutations reflected (effectively) in your address space, without your knowledge or participation.

▲

kiitos 2 days ago | parent | next [-]

I am not really sure what you're talking about

RPC is "remote procedure call", emphasis on "remote", meaning you always necessarily gonna be serializing/deserializing the information over some kind of wire, between discrete/different nodes, with discrete/distinct address spaces

a client request by definition can't include anything that can't be serialized, serialization is the ground truth requirement for any kind of RPC...

a server doesn't provide "an object" in response to a query, it provides "a response payload", which is at most a snapshot of some state it had at the time of the request, it's not as if there is any expectation that this serialized state is gonna be consistent between nodes

	▲	2 days ago \| parent \| next [-]
		[deleted]
	▲	closeparen 2 days ago \| parent \| prev [-]
		Nothing stops me from implementing a Thrift or gRPC handler that uses a field from the request to look up an object in a hashmap and then call one of its methods with data from the request. But a distributed object system will do this implicitly on my behalf, so that the programmer’s perspective is like passing objects (by reference) over the network.

▲

kentonv 4 days ago | parent | prev [-]

That's exactly what Cap'n Web does...