WebSocket transport

[space55]

Hello,

Is there any plan to support WebSocket transport with this library? I can dive in and see if I can implement and PR it, if it would be appreciated.

Thanks!

[sbinet]

hi,

AFAIK, there are no plans to add websocket support.
but PR would be of course welcomed!

[space55]

I've got client-side WS support completed in my fork of the project. I completed that because I desperately needed it for what I was working on (did you know that your library can be easily compiled to WASM?), and will start working on server-side WS support soon.

[sbinet]

as the main goal of that library was to provide a pure-Go implementation of ZMQ, being easily compiled to WASM isn't completely a surprise but it's still nice to know :)

[space55]

So, I've gotten as far as writing a client-side implementation of WebSocket transport. It's a really simple commit + fix, but it introduces another dependency. I'm not too sure how the opinion of additional dependencies fares, but in my mind at least, it doesn't entirely make sense to add a WebSocket dependency for those who are using IPC only. Is there a way to submodule it, or conditionally import?

Otherwise, would something like the ability to pass in functions structured like net.Dial make sense? Or some other way to modularize it.

The fork is under my account (https://github.com/space55/zmq4), and I'm happy to PR it if you'd like the changes now, or I can wait until I have server-side completed as well - up to you.

[sbinet]

nhooyr.io/websocket seems like indeed quite a large dependency (looking at the additional entries to the go.sum fie, that is).

perhaps we could devise a plugin mechanism "a la database/sql to side-step this? (but explicitly registering a new transport mechanism instead of a side effect of blank importing some package)

WDYT?

[space55]

I'm definitely a fan of the idea of a plugin mechanism. I'm not quite sure how it would look from an implementation perspective, but I imagine it would be some sort of struct that is passed to an init function, much like from one of the MySQL drivers:

func init() {
	sql.Register("mysql", &MySQLDriver{})
}

I'm absolutely happy to implement this, but I can see a lot of very compelling reasons why you may prefer to. I shall follow your lead.

[sbinet]

see go-zeromq/zmq4#94 for a possible transport plugin mechanism.

[sbinet]

ping?

[space55]

Thanks, sorry for the late reply. I'll start working out WS & WSS for the plugin mechanism