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

Realtime: there is no dedicated object to manage connections #36

Closed
ricardopereira opened this issue Oct 28, 2015 · 8 comments
Closed
Labels
bug Something isn't working. It's clear that this does need to be fixed.

Comments

@ricardopereira
Copy link
Contributor

No description provided.

@mattheworiordan
Copy link
Member

Ok, this in itself is not necessarily an issue, however are you therefore implying that all of RTN* cannot be supported, without a refactor i.e. we need a Connection object, but whether it is managed with a ConnectionManager or a state machine for example, is not necessarily part of the spec.

@mattheworiordan mattheworiordan added the bug Something isn't working. It's clear that this does need to be fixed. label Oct 28, 2015
@ricardopereira
Copy link
Contributor Author

@mattheworiordan There is no Connection object either. The Realtime client instances a Transport object and connects to the server with the current WebSocket. Just one connection per client.

@mattheworiordan
Copy link
Member

@ricardopereira that is fine, other than the ably-js library, there is only ever one transport open using WebSockets, and in all libraries there is only ever one Connection open as well. As a workaround, we could perhaps simple create a Proxy Connection object that exhibits the properties described in the spec, but simply references the attributes in the Client itself. That way, we don't need to refactor now, and can easily do it later without changing the interface. WDYT?

@ricardopereira
Copy link
Contributor Author

Well, the connection is handled on the ARTWebSocketTransport. I can add a protocol to mirror the existing methods from ARTRealtime. Like you said, a proxy Connection object. It's the best workaround.

@mattheworiordan
Copy link
Member

BTW. What happens when the transport is closed & re-opened (such as connection failure), does the ARTWebSocketTransport remain consistent or is a new object created each time?

@ricardopereira
Copy link
Contributor Author

The object remains consistent.

On Wednesday, 28 October 2015, mattheworiordan [email protected]
wrote:

BTW. What happens when the transport is closed & re-opened (such as
connection failure), does the ARTWebSocketTransport remain consistent or
is a new object created each time?


Reply to this email directly or view it on GitHub
#36 (comment).

@mattheworiordan
Copy link
Member

Ok, great, well lets go with a proxy object for now as that will allow us to meet the requirements of the spec easily

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working. It's clear that this does need to be fixed.
Development

No branches or pull requests

2 participants