> BTW, there is another issue that needs to be considered.
> https://github.com/apache/pulsar-client-go/issues/919
Thanks. Yes, we need to consider that.
BR,
Zike Yang
On Tue, Apr 2, 2024 at 10:50 AM Zixuan Liu wrote:
>
> > We maintain two versions of the API, but they could share the same
> in
> We maintain two versions of the API, but they could share the same
internal code.
Thanks for your explanation! +1
Jie crossover 于2024年4月1日周一 22:20写道：
> Greet plan.
> > We maintain two versions of the API, but they could share the same
> > internal code. I don't think this will add much compl
Greet plan.
> We maintain two versions of the API, but they could share the same
> internal code. I don't think this will add much complexity.
I agree with this.
BTW, there is another issue that needs to be considered.
https://github.com/apache/pulsar-client-go/issues/919
--
Best Regards！
cros
> This would lead to inconsistency in API definitions, making them
> appear disorganized.
I agree. Using such suffixes is really ugly and much harder to
maintain IMHO. It only makes people add APIs more casually. They might
think, oh, don't worry, if this API (e.g. doSomething()) does not make
sen
Thanks for all your comments. I address each one in line.
> Regarding the `Close` method, I think it's exceptional. It's designed
to return no error so that users can call `defer client.Close()` [1].
To process errors in `Close()`, we can panic in the implementation and
let users use `recover` to
I don't recommend breaking user APIs. There are many ways we can avoid it.
> 1. We should support passing the context to some IO-related methods
like `Ack`, `Close`, `Flush`, etc, or any other methods. There is an
issue related to this discussion. [2]
We can add a method with context, so like: Cl
The plan looks great.
I’d add one more item for consideration: using WithX() methods instead of
a strict for configurations:
https://github.com/apache/pulsar-client-go/issues/68
--
Matteo Merli
On Fri, Mar 29, 2024 at 5:38 AM Zike Yang wrote:
> Hi, everyone
>
> The Pulsar Go Client[0] is n
Regarding the `Close` method, I think it's exceptional. It's designed
to return no error so that users can call `defer client.Close()` [1].
To process errors in `Close()`, we can panic in the implementation and
let users use `recover` to catch the panic.
[1] https://github.com/apache/pulsar-client
Hi, everyone
The Pulsar Go Client[0] is now relatively mature. I've also noticed
that many people in the community have widely used it in their
production environments. However, there's still no official 1.0
version for the Go client. I would like to start a thread to discuss
the plan for releasin
