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

GH: Receiver can't use memory/disk transport #291

Closed
AlanRynne opened this issue Mar 5, 2021 · 1 comment · Fixed by #585
Closed

GH: Receiver can't use memory/disk transport #291

AlanRynne opened this issue Mar 5, 2021 · 1 comment · Fixed by #585
Assignees
Labels
bug Something isn't working grasshopper issues related to the grasshopper connector.

Comments

@AlanRynne
Copy link
Member

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.

Screenshot 2021-03-05 at 16 59 42

@AlanRynne AlanRynne added bug Something isn't working grasshopper issues related to the grasshopper connector. labels Mar 5, 2021
@AlanRynne AlanRynne self-assigned this Mar 5, 2021
@AlanRynne
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working grasshopper issues related to the grasshopper connector.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants