Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SyphonClient could join subsequent similar servers #23

Open
bangnoise opened this issue Mar 31, 2015 · 0 comments
Open

SyphonClient could join subsequent similar servers #23

bangnoise opened this issue Mar 31, 2015 · 0 comments
Milestone

Comments

@bangnoise
Copy link
Member

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant