Hi Dennis, On Sat, Jul 01, 2017 at 01:37:52AM +0200, Dennis Jacobfeuerborn wrote: > I had to deal with this issue recently as well but I'd rather like to > see a more explicit and well defined response in all cases rather than > the workaround proposed above. > Its not clear why a warning should automatically mean the command was > unsuccessful and identifying a specific error still requires string > matches which breaks all clients the moment the wording is changed or a > typo is fixed. > > I'd rather see something along the lines of error codes i.e. 0 for "Ok" > and anything else for specific errors followed by the message e.g.: > > 0:Ok > 1:No such backend > 2:No such server in backend > etc. > > This would allow tools working with the socket to always get consistent > responses and enable them to only parse the response code to identify > the response regardless of the message.
This would do the opposite and force all tools to be constantly updated to learn new codes. Even worse, you'd end up with multiple parallel registries because most of the time contributed patches have been used for some time internally, and multiple commands would end up using the same status codes. We could use a number of the severity instead of using a word, but in general it seems important to me that the codification is made once for all so that tools don't have to be modified in the future. Also what I like with the severity/error levels is that some commands currently return confusing output, which some people would understand as an error and others as a warning or a notice that the operation was performed but differently. With an error level indication it becomes much clearer if that partially succeeded or failed. We've already had some demands to log cli actions, and I tend to think that using syslog-compatible levels could make this more generic for all current and future contributions. > This could either be introduced only in the current development version > because of the compatibility breakage or a parameter could be introduced > to configure the socket with the new "protocol". If that parameter is > not set then the code could simply not be sent in the response and > messages would be returned just as they are now. This is a good idea. We could for example have a CLI command to enable error code reporting in front of messages. It could become the default in a future version, keeping an option on the stats socket config line to go back to the current output. Cheers, Willy
