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
Looked into this and as quickly discussed with @didimitrie, our current StreamWrapper and Transport implementation slightly conflict. Works fine for sending, but receiving requires extra information that we're currently unable to pass (object ID, name in memory...).
It is basically the same problem we were having with the ServerTransport initially, as it didn't hold all the data we needed, and the reason StreamWrapper exists in the first place:
The ServerTransport only knows about how to send/receive from a server
The StreamWrapper knows how to parse server urls, fetch the appropriate account, determine what type of stream url was provided (commit, branch...) and do basic validation.
The only way I could see this working on is to create an abstract TransportWrapper class (with its corresponding GH parameter, just as StreamWrapper is implemented now).r
This would allow all transports to behave consistently throughout all connectors, but will include a new layer programmers would have to know about for their custom transports to work in Visual Programming environments (GH/Dyn) and more docs to be written 📖 😝
On the bright side, it would also clean the code in the send/receive nodes, and would future proof our implementation for any community transports that may come down the line.
That being said... this doesn't look like it's going to be 100% straightforward if done correctly, so it needs further discussing.
Receiver throws an unhandled error when connecting any transport other than the
ServerTransport
.I'm not debugging GH so I'll just open this issue and figure the reason why this happens later.
The text was updated successfully, but these errors were encountered: