You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
Formally support on-prem hosting by allowing organisations to host their own teletype-server and pub-sub solution (to replace pusher).
Motivation
Currently, although I can run my own teletype-server, I am unable to run Teletype at my organisation because the pusher dependency suffers from connectivity issues via proxies and violates some regulations that my organisation is bound to in terms of restricting access to some code. It would be great to formally support an on-prem option including finding an alternative pub-sub.
Describe alternatives you've considered
Although teletype allows customising the server, the pusher dependency can not be customised.
I have also tried manually installing a branch of these modules from the PRs referenced below that inspired this issue, and although it is possible to do this, all participants of Teletype would have to go through this setup which doesn't scale very well given that for many Atom is not their primary IDE.
Additional context
I have reviewed the existing PRs which attempt to do this, which took some setup before I managed to get them to work properly across multiple devices: #393 atom/teletype-client#67 atom/teletype-server#50
Since the PRs above actually go beyond just Pusher, including custom ICE and IdentityProviders, I suggest that for now this feature only focus on the PubSub, with socketcluster seeming like quite a good alternative.
I suggest the following changes:
teletype
Upgrade the atom API server base URL to a main configurable parameter rather than Dev parameter.
Add Dev parameters
PubSub provider [pusher, socketcluster]
SocketCluster URL
All Dev parameters act as an override only, and will be optionally passed to teletype-client
teletype-server
Add configuration parameters for PubSub (similar to the client-side)
Add a new end-point to retrieve the PubSub details (similar to how ICE discovery is provided now)
Increment api-version
teletype-client
After determining protocol-version, if compatible, request pub-sub details
Apply user overrides if provided
Instantiate the deduced pub-sub implementation
I'll be happy to elaborate in more detail in an RFC if required
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Summary
Formally support on-prem hosting by allowing organisations to host their own
teletype-server
and pub-sub solution (to replace pusher).Motivation
Currently, although I can run my own
teletype-server
, I am unable to run Teletype at my organisation because the pusher dependency suffers from connectivity issues via proxies and violates some regulations that my organisation is bound to in terms of restricting access to some code. It would be great to formally support an on-prem option including finding an alternative pub-sub.Describe alternatives you've considered
Although
teletype
allows customising the server, the pusher dependency can not be customised.I have also tried manually installing a branch of these modules from the PRs referenced below that inspired this issue, and although it is possible to do this, all participants of Teletype would have to go through this setup which doesn't scale very well given that for many Atom is not their primary IDE.
Additional context
I have reviewed the existing PRs which attempt to do this, which took some setup before I managed to get them to work properly across multiple devices:
#393
atom/teletype-client#67
atom/teletype-server#50
Since the PRs above actually go beyond just Pusher, including custom ICE and IdentityProviders, I suggest that for now this feature only focus on the PubSub, with socketcluster seeming like quite a good alternative.
I suggest the following changes:
teletype
API server base URL
to a main configurable parameter rather than Dev parameter.teletype-server
teletype-client
I'll be happy to elaborate in more detail in an RFC if required
The text was updated successfully, but these errors were encountered: