Just to be a voice of dissent, I’m a -1 vote for using SyphonNameboundClient – it is intended for things such as plugins where the plugin API dictates that the name and app name parameter are not allowed to change, whereas in a programming environment like Processing, it’s perfectly fine to have properties of the object change over time.
However vade suggested it because you could instantiate a client from a name/app-name pair, which I think is a useful feature for a client object, as he says, to avoid passing the dictionaries the framework uses. Wrapping those as some sort of token object would also be acceptable though. If you want to instantiate clients from name/app-name pairs then SyphonNameboundClient may have useful code to rip out for finding matching servers, just don’t use the whole class as-is.
I think SyphonServerDirectory (to mirror the framework’s naming) would be a useful addition. Hopefully it could deliver app and server name pairs rather than just server names (some servers may have no name).
Most of all though, thanks for giving this thought and time!