> What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possi

> What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. Suppose it turns out that your MF RPC (or however your API is implemented) works too slowly, and instead of passing whatever through TCP, you are going to generate a file accessible through the shared MF/non-MF file system with the relevant contents. If all it takes is calling up Frank in the MF programming department to do the MF side (or even better, doing it yourself) -- then, no, it's not an API any more than your private class names and functions are an API - the MF/non-MF dividing line (which will likely also separate operating systems, programming languages, etc) is of no consequence, because there's no negotiation around changing it. I have witnessed exactly such a power struggle last time I worked in an environment that had mainframes (some 25 years ago) - functionality that was available on the MF was needed on a unix workstation. The amount of dev work on the unix side to do a mainframe RPC or to do it from scratch was comparable. From most perspectives, the unix re-implementation was a pure win. It sounds like a clear-cut decision, but the MF people argued fiercely against it -- to the best of my understanding, because they were constantly losing turf and relevance. Would you not call this political?