SyphonClient could join subsequent similar servers

[bangnoise]

From Google code:

Reported by bangnoise, Nov 18, 2010
Currently a SyphonClient is created with credentials for one instance of a SyphonServer. When the server dies, the client is no longer useful. If an identical server is subsequently created, it is up to the host app to observe this and create a new SyphonClient

Perhaps:

1. after the termination of its initial server, SyphonClient watches for the arrival of later servers with similar credentials (name and app-name) and returns frames from them
2. an option key, SyphonClientOptionStayAlive, is added to pass to SyphonClient at init to take a NSNumber with bool value to enable/disable this functionality.
3. this functionality is enabled by default
4. SyphonServer gains an option key, SyphonServerOptionIdentifier, to take a NSString which identifies a server across incarnations. If this is present, it will be used instead of name/appname to match subsequent servers in a client.

comments?
Nov 18, 2010 vade@vade.info
4. Seems redundant to me. Would not matching the Application name and Server name be equivalent to having a new "SyphonServerOptionIdentifier", no?

I say, if anything, 1, 2, and 3. This seems like something SyphonNameBoundClient can have, if gets rolled into the framework proper?
Nov 19, 2010 bangnoise
1, 2, and 3 suggest we roll it into SyphonClient. The only change to the API would be the additional NSString const SyphonClientOptionStayAlive to be passed in the options dict for SyphonClient.

Because this behaviour is what I imagine 99% of people want, I think it makes sense to make it the default, rather than having it in an extra class (something like SyphonNameBoundClient).

1. because you could have two servers with the same name, but different functional identities, and some people might want a more certain way to attach to a server (eg if you're using SyphonServerOptionIsPrivate to communicate with a daemon). We could tighten up the documentation for naming servers and encourage uniqueness, but even then this seems more certain..?
   Apr 16, 2011 bangnoise
   Vote against my own 4, only postpones the issues with identical names rather than resolving them, moving milestone to sooner (obviously should be beta'd before release)
   Labels: -Milestone-Release1.0 Milestone-PublicBeta2
   Apr 17, 2011 anthony.stellato
   I'm one of the 99%, voting for 1, 2, and 3, no on 4.