Software -- legacy software, which is always all software currently in use, which is an enormous code base.
It would be easier to have a drop-in replacement for TCP that, whenever it can work, connect() will use it, and which listen()/accept() will work with as well as TCP. Then all apps that can use TCP could use the new transport transparently.
Basically, we need a TCP++ that works with existing APIs but which can also provide new functionality via new APIs.
Of course, backwards-compatibility is very limiting, which sucks.
We can also have new transports that have new APIs, but we need a better TCP for backwards compatibility because legacy is forever.
Also, the focus on RPC is cool because any protocol where you typically have a library doing the I/O -and not too many such libraries- is amenable to using the new thing, and that includes HTTP (which isn't an RPC). But TFA really needs to mention HTTP in the same breath as RPC, because -sadly- way too many readers will just close the tab as soon as they see "RPC" and not "HTTP".
It would be easier to have a drop-in replacement for TCP that, whenever it can work, connect() will use it, and which listen()/accept() will work with as well as TCP. Then all apps that can use TCP could use the new transport transparently.
Basically, we need a TCP++ that works with existing APIs but which can also provide new functionality via new APIs.
Of course, backwards-compatibility is very limiting, which sucks.
We can also have new transports that have new APIs, but we need a better TCP for backwards compatibility because legacy is forever.
Also, the focus on RPC is cool because any protocol where you typically have a library doing the I/O -and not too many such libraries- is amenable to using the new thing, and that includes HTTP (which isn't an RPC). But TFA really needs to mention HTTP in the same breath as RPC, because -sadly- way too many readers will just close the tab as soon as they see "RPC" and not "HTTP".