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
Instead of redialing transports and get them from the transport discovery on startup, we should make it easy and straightforward to setup automatic transports which we have prepared in #743 and in #697 . Users should not be required to make too many manual transport requests anymore and thereby the need to keep track of these manual transports being setup is not given anymore. If necessary, we could also store the intention to always setup a given transport on the client . This would not require us to keep track of all the down transports in discovery.
Describe the solution you'd like
remove redialing logic for transports that are down
remove call to tp disc on startup to get registered transports --> restarted visor does not have any transports initially
change entry of transport to remove status field (up/down)
make sure we delete transports that are closed in transport discovery
make sure we call deletion of transports when transport breaks or is closed
Additional context
I have considered adding a lastactive timestamp to transports to make sure we expire them if they are inactive but no visor made the call to delete the transport. Something of that sort is going to be needed.
I also considered adding a template function that allows a user client side to specify they want to always setup a specific type of tp to a given remote. That'd be more elegant solution to still provide the functionality we provide right now.
The text was updated successfully, but these errors were encountered:
Feature description
Instead of redialing transports and get them from the transport discovery on startup, we should make it easy and straightforward to setup automatic transports which we have prepared in #743 and in #697 . Users should not be required to make too many manual transport requests anymore and thereby the need to keep track of these manual transports being setup is not given anymore. If necessary, we could also store the intention to always setup a given transport on the client . This would not require us to keep track of all the
down
transports in discovery.Describe the solution you'd like
Additional context
I have considered adding a lastactive timestamp to transports to make sure we expire them if they are inactive but no visor made the call to delete the transport. Something of that sort is going to be needed.
I also considered adding a template function that allows a user client side to specify they want to always setup a specific type of tp to a given remote. That'd be more elegant solution to still provide the functionality we provide right now.
The text was updated successfully, but these errors were encountered: