In order to allow TokBox to deploy new and more experimental features to the Nightly and Aurora clients, they want us to use different API keys for calls initiated by Nightly and Aurora clients than we do for Beta, Release, and standalone clients. This requires client changes (indication of release channel); network API changes; and server changes (storing two API keys, and varying them based on the indicated calling party release channel). We also need a new set of keys for the Nightly/Aurora clients. I will be filing sub-bugs for each of these four items (hence the needinfo to myself)
Will this limit interoperability if different clients (Web UI, FFOS or client UI) use different API keys?
How will the Loop development team be notified of these behind-the-scenes changes before they are deployed so that we can coordinate risk-management ahead of time, as well as know when it might make sense to reach out to Tokbox while debugging?
(In reply to Romain Testard [:RT] from comment #1) > Will this limit interoperability if different clients (Web UI, FFOS or > client UI) use different API keys? Keep in mind that the API key is in possession of the server, not the clients. It uses this API key to set up the call with the TokBox servers. So, for any given call, there will be only _one_ API key in use per call, selected by the _server_ based on the release channel of the _calling_ party. The plan, from conversations with Rob, is that this should provide at least basic interoperability between the clients. Under circumstances in which, say, a Nightly user calls a Release user, they will end up on a Nightly TokBox server, which may include features that the Release client cannot activate. Similarly, if the Release user calls a Nightly user, they will be on a Release TokBox server; if the Nightly user attempts to use a feature that the Release TokBox server does not support, then such attempts will fail. In both cases, the subset of features shared by both clients should continue to work.
(In reply to Dan Mosedale (:dmose - needinfo? me for responses) from comment #2) > How will the Loop development team be notified of these behind-the-scenes > changes before they are deployed so that we can coordinate risk-management > ahead of time, as well as know when it might make sense to reach out to > Tokbox while debugging? My understanding is that such changes will be coupled with new releases of the SDK; so we will be informed by means of having to install a new SDK into our repo. :) Essentially, this doesn't change the coordination that takes place regarding feature releases; it simply uncouples Nightly/Aurora features from Beta/Release features, so that TokBox can try new stuff out more rapidly.
Tokbox is preparing the server environment for Beta/Release now. A couple of questions to help us: - Will the API key that is currently in use for Nightly/Aurora stay with Nightly/Aurora or will it be used with Beta when Beta is released? - What will be the new API key that you will use for the other environment?
(In reply to Rob Hainer from comment #5) > Tokbox is preparing the server environment for Beta/Release now. A couple of > questions to help us: > - Will the API key that is currently in use for Nightly/Aurora stay with > Nightly/Aurora or will it be used with Beta when Beta is released? > - What will be the new API key that you will use for the other environment? I think we've already switched over to channel-based API keys, but I'm not sure -- so that makes "currently" a slight bit ambiguous. Once the dust is settled, Nightly/Aurora will use 44667562, while Beta/Release/Mobile/Standalone will use 44835892. I believe that we're still using 44669102 for server development. Alexis: can you confirm whether we're currently set up as I describe? Thanks.
This will happen with the upcoming 0.10 release (should be in prod next week, tracked in bug 1048990).
Actually this is planned for the 0.12.5 release to Loop-Server. See bug 1082922
This is done via Loop-Server in Stage and Production.
I believe we fixed this a while ago - the only remaining item is bug 1089354 which is cleanup, so I think we can close this bug.