Closed pekam closed 3 years ago
Might make sense to pass an event object to the connection failed callback so that we can e.g. include information about the cause (e.g. lack of quota vs network connectivity issue).
Might make sense to pass an event object to the connection failed callback so that we can e.g. include information about the cause (e.g. lack of quota vs network connectivity issue).
Issue description has been updated to include the event object.
To fix issue #13, there needs to be a way for
openTopicConnection
to inform the caller that the connection failed. This can happen when the end user quota of the license has been exceeded. The same solution could be used also for actual connection problems when running CE as a standalone server.Currently
openTopicConnection
returns aRegistration
for closing the connection. In case of a refused connection, it returns a NO-OP callback. One option would be to returnnull
in this case, but it would not be very obvious, and could easily lead to NPEs.Another option would be to add a new overload of
openTopicConnection
with a callback to handle the potential failed connection:The downside is that the parameter list is already very long, which is a code smell.
A third option, and the one we've decided to implement, is to make
openTopicConnection
return an extended version ofRegistration
:Right now the event doesn't have any useful information, but later when the failure can happen also because of network issues, we can add information about the cause of the failure to the event.
This would be similar to Flow's
DomListenerRegistration
, and could be used inCollaborationBinder
's case like:If the connection has already failed when adding the action, it should be called immediately.
The action should be invoked through
ConnectionContext::dispatchAction
.UPDATE 27 Nov 2020: We don't actually need this API to fix
CollaborationBinder
, as we haveCollaborationEngine::requestAccess
to check if a topic connection can be established or not. This feature might still become useful once CE is running as a standalone server. In that case, it might be beneficial to have a single roundtrip that opens the connection if possible and returns the status.