[dleavitt]

I think the term for this is "location transparency" and it tends not to work well in practice. A local function call and a RPC call over a network have very different performance characteristics and failure modes; trying to abstract away the differences can be a bad scene.

A previous journey down this road: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

[iou]

(author of this blog post..)

I was aware of CORBA, but have never worked with it. I should have added a link out to it, I might do that.

I think most ideas do have necessary conditions to succeed, and perhaps network latency (especially in single VPC) has improved a lot since those days.

The original motivations weren't just network based. The scenario where I wanted to use CAP_LINUX_IMMUTABLE to create append-only log files via EXT4 attr was a good example of where being able to decorate a function to say that it runs in a separate container potentially seemed like a reusable concept.

> trying to abstract away the differences can be a bad scene

Agree, generally I'm against "magic" behavior in code. That's why I quite like the protobuf philosophy of being able to see the generated code at compile time, as opposed to some runtime magic.

What I'm suggesting is just to abstract some of that boilerplate code, but it could still go badly if used without consideration.

[dleavitt]

Makes sense, thanks for the clarification! Do you think it's a good idea to have a "passthru" option at all?