tisonkun commented on issue #1075: URL: https://github.com/apache/pulsar-client-go/issues/1075#issuecomment-1677753609
Thanks for your feedback and participation @flowchartsman! I've submitted a PR https://github.com/apache/pulsar-client-go/pull/1077 for roughly adding the sources of `pulsar-admin-go`, so that we have a baseline to improve and the downstream projects can first migrate to that hash for updating module/pkg path, and later catch up any refactors. Your refactoring suggestions can be applied onto that patch. > [package-level error interfaces along with helper methods](https://github.com/streamnative/pulsar-admin-go/pull/41/files#diff-76a7e0e299c7417bae32d3098e71370980157fe29e68a366671491d147d40572) I like this. > exported Admin field As we discussed on Slack, perhaps a parallel interface design for client API and admin API can be better. This is the design of Java APIs and it reflects that admin APIs (control panel) are at the same level of client API (data panel) - client APIs don't "own" admin APIs. Also, this can make the auth model clear - generally, users configure less permission for client APIs while admin APIs requires high trust level. > Because pulsar-client-go already handles (most) auth plugins natively, the functional auth API I designed for my PR would no longer be necessary, and authentication would come from the auth settings specified in pulsar.ClientConfig This is the right direction. We will factor out shared/common configs and the auth package. But how to reduce the impact for current users is a point that needs a second consideration. > exercise most if not all endpoints using an actual pulsar container This is cool! We definitely need it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
