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
Justin noticed that Pollymer seemed not to be behaving as expected, as he was not seeing the "waiting X ms" notice between updates.
Upon investigation, I found that this is because every time the Link URL changes, a new connection is created, resulting in the creation of a brand new Pollymer object. Justin says that he expects Pollymer objects to be reused in this case.
In order to allow for multiplexing, the engine currently collects all resource handlers that have the same link URL and creates a single connection object that references all these resource handlers. Even in the case where multiplexing is not used, unrelated resources may happen to return the same wait link endpoints, and in this case a single connection object is used to represent both objects.
Because of this handling, it is possible to easily switch objects between multiplexing and singleplexing, or to multiplex-websockets when necessary.
In order to reuse Pollymer objects, it would need to become possible to track each resource handler from each connection, and then detect when an adjusted link URL points to one of the resource handlers referred to by an existing connection, and then mutate that connection. This could result in the branching of multiple connections from a single connection, or the converging of connections.
The text was updated successfully, but these errors were encountered:
Justin noticed that Pollymer seemed not to be behaving as expected, as he was not seeing the "waiting X ms" notice between updates.
Upon investigation, I found that this is because every time the Link URL changes, a new connection is created, resulting in the creation of a brand new Pollymer object. Justin says that he expects Pollymer objects to be reused in this case.
In order to allow for multiplexing, the engine currently collects all resource handlers that have the same link URL and creates a single connection object that references all these resource handlers. Even in the case where multiplexing is not used, unrelated resources may happen to return the same wait link endpoints, and in this case a single connection object is used to represent both objects.
Because of this handling, it is possible to easily switch objects between multiplexing and singleplexing, or to multiplex-websockets when necessary.
In order to reuse Pollymer objects, it would need to become possible to track each resource handler from each connection, and then detect when an adjusted link URL points to one of the resource handlers referred to by an existing connection, and then mutate that connection. This could result in the branching of multiple connections from a single connection, or the converging of connections.
The text was updated successfully, but these errors were encountered: