TSDebug has a variant, `TSDebugSpecific` that people can use to enable debugging on demand. Should those new methods have the same variant?
Is the difference between `TSStatus` and `TSNote` significant enough to require two methods? I would expect the logging api to be consistent with other standard logging apis, and it might make more sense to follow known log levels (debug, info, warning, error, fatal) than creating new ones with small nuances in meaning. What do you think? On Tue, Sep 8, 2020 at 12:38 PM Susan Hinrichs <[email protected]> wrote: > +1 > > On Tue, Sep 8, 2020 at 1:34 PM Alan Carroll < > [email protected]> wrote: > >> +1. >> >> On Tue, Sep 8, 2020 at 12:04 PM Aaron Canary <[email protected]> >> wrote: >> >>> I'd like to propose adding API calls for the remaining methods in diag.h: >>> TSStatus(const char *fmt, ...) // prints to diags log (informational) >>> TSNote(const char *fmt, ...) // prints to diags log (implies >>> significance) >>> TSWarning(const char *fmt, ...) // prints to diags log (implies concern) >>> TSAlert(const char *fmt, ...) // exit and restart, prints to diags >>> log (implies needs attention) >>> >>> The following are already exposed through the API: >>> TSDebug(const char* tag, const char *fmt, ...) // print to stderr >>> TSError(const char *fmt, ...) // prints to diags log (implies operation >>> failure, causes test fail in CI) >>> TSFatal(const char *fmt, ...) // exit and restart, prints to diags log >>> TSEmergeny(const char *fmt, ...). // exit and don't restart, prints to >>> diags log >>> >>> I'd like to add these to the TS API, and update the documentation to >>> directly describe the uses of each. I'm not interested in changing any >>> functionality of diags.h/.cc at the moment, just exposing for plugins to >>> use. >>> >>> Corrections? Major objections or concerns? >>> I'll reply here with the PR when it's ready. That might be a better >>> forum to discuss the details. >>> >>
