You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pulsar.apache.org by Apache Pulsar Slack <ap...@gmail.com> on 2018/05/08 09:11:01 UTC
Slack digest for #general - 2018-05-08
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
----