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

Accept rawChannel or url for VncScreen component #42

Open
1 task done
sklymoshenko opened this issue Dec 1, 2022 · 2 comments
Open
1 task done

Accept rawChannel or url for VncScreen component #42

sklymoshenko opened this issue Dec 1, 2022 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@sklymoshenko
Copy link

Is there an existing issue for this?

  • I have searched existing issues, it hasn't been reported yet

Use case description

Basically we have our own required implementation of creating a ws connection. We are not relying on third-part libraries to do it for us. It covers for us security and auth etc.
noVnc package has support for accepting either url or already created ws channel to work with.

export default class RFB extends EventTargetMixin {
    constructor(target, urlOrChannel, options)     

So i am offering to accept not only url as string but alrerady created data channel and pass it to a rfb constructor.
Wath do you think ?

Thank you!

Proposed solution (optional)

No response

@roerohan
Copy link
Owner

roerohan commented Jan 5, 2023

Seems fair, if noVNC supports it, this library should as well. Right now, if type-safety isn't a concern, I think you can still pass a raw channell object to the url field in VncScreen and it'll still work (as is evident from the following line(s) of code).

const _rfb = new RFB(screen.current, url, rfbOptions);

I could make a change wherein if the url is absent but a channel is present, I pass that to the RFB constructor. If both are present however, it would accept the url field. (P.S. I don't want to make it urlOrChannel since I want it to be typed distinctly). Does this solution sound good? What do you think?

@roerohan roerohan self-assigned this Jan 5, 2023
@roerohan roerohan added the enhancement New feature or request label Jan 5, 2023
@roerohan
Copy link
Owner

@sklymoshenko could you share your thoughts on this? I'll update the source accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants