2018-05-07 10:27:31 UTC - Vasily Yanov: still see "Connection was closed while the opening the cursor" ---- 2018-05-07 13:41:35 UTC - Byron: @Matteo Merli @Josh West I created a Go client using the websocket protocol as a temporary solution: <https://github.com/bruth/go-pulsar-ws> +1 : jia zhai ---- 2018-05-07 13:43:02 UTC - Byron: i made it for my needs and will likely abandon it once a client using the binary protocol comes out. but i am sharing in case someone finds it useful and also could start discussion around the API design. i have the Godoc link on the README to see the API ---- 2018-05-07 17:42:40 UTC - Matteo Merli: Nice! Thanks @Byron. I’ll take a look at it. Since I’m a just getting started with Go, it would be definitely needed to have help in shaping the API :slightly_smiling_face: ---- 2018-05-07 17:43:22 UTC - Byron: The API can be improved, but it closely models the simplicity of the other clients. ---- 2018-05-07 17:43:36 UTC - Byron: Happy to answer questions and work together on a better API ---- 2018-05-07 17:45:07 UTC - Matteo Merli: Great, I’m getting a first tiny part of wrapping working and I’ll post here once the C -> Go is mostly complete ---- 2018-05-08 00:22:33 UTC - Byron: @Matteo Merli I think a good strategy would be to define the API as a set of interfaces that then the transports can implement. That said I am not sure if there is complete parity in producer, subscriber, and reader options between the two transports. ---- 2018-05-08 00:25:49 UTC - Matteo Merli: Yes, I was exactly going like that. Interfaces also have the good property of enforcing to pass by ref, which is important when the structs hold C pointers, which needs to be freed at some point :slightly_smiling_face: ---- 2018-05-08 00:26:07 UTC - Byron: Good deal ---- 2018-05-08 00:27:27 UTC - Matteo Merli: > That said I am not sure if there is complete parity in producer, subscriber, and reader options between the two transports.
Yep, the options are typically tied to the actual implementation ----
