Naming Bi-Directional Streams In an API?
DingoTango writes "My coworker and I are designing an infrastructure API to manage data streams. It will allow a client developer to set up streams going to and from some invoked server functionality, and allow a server developer to write services that both consume and produce streaming data. Our quite civil disagreement involves naming: From the perspective of the client platform, the client's output stream goes to the server, and input stream comes from it. For the purpose of any ensuing discussion, let's call this the 'Local' perspective. However, if the client developer considers the service to be a widget, then the stream going to the service is the input stream and the stream coming from it is the output. Let's call this the 'Widget' perspective. As this is an infrastructure utility, we aren't able to name the streams according to function. What say ye, Slashdot? Is there any precedence, experience, or ungrounded yet vociferous opinion that will resolve this for us?"
Why not call them the "client to server" stream and the "server to client" stream?
UploadStream: data goes to a server.
DownloadStream: data goes from the server.
The syntax from socket programming, like send, receive, and listen, seems well suited for situations where both sides can act as clients or servers. Both sides would use the same syntax, each naming things from its own perspective.
...I think you want StackOverflow which is a few clicks that way ------>
although "eat me" "drink me" is a close second