Slashdot Mirror
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?
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.
Not really. Ask Slashdot has always had a little niche for this.
It's a fun question, too. I'd suggest naming them directions that don't correspond to client-server relationships in such an obvious way. So, instead of Up and Down, go for North and South, whichever way feels more appropriate to the situation. In and Out might be a good pair, depending what you want to visualize.
How about Hitherwise and Yonderborne?
although "eat me" "drink me" is a close second