ctubbsii commented on PR #2180: URL: https://github.com/apache/zookeeper/pull/2180#issuecomment-2295300826
> @ctubbsii Thanks for reviewing. I replied inline here: > > > had to deal with encoding quirks of different terminals, > > Could you explain more about this? IMO, `base64` or `hexdump` are just different view of the byte array, it should not involve any encoding problem (a terminal not support ascii?). The encoding problems I was referring to aren't with base64 or hex, but with String encoding, which is not part of your PR, but already assumed by zkCli. (For example, some terminals allow you to type in non-printable characters or multi-byte unicode characters, which JLine can mangle if its settings don't match your terminal settings.) The problem isn't really the addition of base64 or hex, but the addition of more code paths for the user to consider, making it harder for users to predict the behavior of zkCli. Users may be able to deal with the quirks of one code path, but when multiple are added, it becomes harder to predict what the actual underlying bytes are going to be. For example, while I mentioned some specific quirks with JLine mangling unicode characters if terminal settings don't match in the String entry case, the base64 entry adds addition quirks, because there isn't a single base64 encoding scheme. There are **many** base64 encoding schemes. See https://en.wikipedia.org/wiki/Base64#Variants_summary_table . There are also different hex encoding schemes https://en.wikipedia.org/wiki/Hexadecimal > > > user requests for even more different kinds of serialization, custom formats, etc. > > IMO, domain-related serialization or formatting is beyound the general support area of the Zookeeper CLI. I agree. That was kind of my point. I'd consider binary data to fall into the category of domain-specific serialization. > > > I can understand how adding this seems like it would be a useful addition. However, in my experience, all it is likely to do is allow users with specific binary requirements to start depending on the zkcli tool for more than simple triage and troubleshooting, and will run into a lot of edge cases when they start to rely on it more. That will increase the maintenance burden and code complexity, without a lot of actual benefit to users. > > In my scenario, I need to see the actual znode data when troubleshooting with application build around Apache Zookeeper e.g. Apache Pulsar, I do it by now is write an one-time only program to get znode data and print it in base64. If zookeeper cli supports it, it should provides convience with troubleshooting with binary znode data. My preference would be to not modify the zkCli interactive shell. Instead, I would prefer a better tool that can interact directly with the user's terminal. So, if you need base64 encoding or hexdump, you can do something like `bin/zk get /path/to/node | base64` or `<something.bin bin/zk set /path/to/node --digest-auth "secret"`. That way, instead of baking in new features into the zkCli, users can more easily take full advantage of the wide variety of existing tools available to them on the command-line. -- 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: notifications-unsubscr...@zookeeper.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
