Hi Arapit, thanks for the suggestions.
Optional identifier sounds good.
One use case of multiple handlers is for refreshing something on two servers running on two ports. We would ideally like to return a repeated custom message type which includes returnCode, userMessage, and senderName (which becomes important when you have multiple handlers). And then that opens another issue with how to have a user-readable senderName.
Perhaps supporting multiple handlers isn't worth the hassle?
Changes sound good if we need to support multiple handlers.
Args are sent as an array of strings, no post-processing done.
Not sure if it needs to be there, but other refresh calls are able to infer the host:port based on the protocol used (and the refresh protocols they use are specific to NN or DN) whereas a generic protocol would not.
It seems like a handful of these changes depend on whether or not it supports one identifier to many handler mappings. In the process the code gets more complex since we're now dealing with collections of responses.
Let me know if the feature sounds useful, otherwise I can remove it to maintain simplicity.