4 ms·
I’m not a fan of the way this presents interfaces. It’s quite nebulous, and despite coming close to the mark, it doesn’t appropriately distinguish between data
by sevensor 2y ago
I’m not a fan of the way this presents interfaces. It’s quite nebulous, and despite coming close to the mark, it doesn’t appropriately distinguish between data and transport. It seems like what it’s trying to get at is that you can ignore how transport works in an exchange of data, sometimes, right up to the point where it turns into a problem.
- prospero 2y agoThe point is that an interface should help you to both ignore and understand the underlying implementation. I'm not sure I understand your point about data and transport, since most interfaces (e.g. names) don't touch the network. Are these just synonyms for interface and implementation?
- sevensor 2y agoI bring it up because the author was talking about network transparent APIs, where the developer doesn’t have to care about whether the call goes over the network. But of course this is not something you can actually afford to ignore. It’s quite a different concern from the data exchange that happens between application and API, however.
- prospero 2y agoYes, and that is used as an example for the general point: a network transparent API doesn’t help us understand the network when it inevitably fails.
- wduquette 2y agoI was on a project once that developed an IPC API based on remote procedure calls. The first thing they did was hide the RPCs, precisely for this reason. And the second thing they did was ditch the RPCs in favor of TCP/IP socket reads and writes, because once you hide them the RPCs don’t buy you anything but headaches. Bye bye DCE.