Logging: review once again #1639
Labels
Azure.Core
Client
This issue points to a problem in the data-plane of the library.
design-discussion
An area of design currently under discussion and open to team and community feedback.
feature-request
This issue requires a new behavior in the product in order be resolved.
Milestone
Verbose
, or Warning, or something else?Azure::Core::Logging::
namespace, or should we make a class?std::function
, or something else for callback?string componentId
? (other proposal was string serviceId) Or don't? Or not a string, but some enum?Victor had cool proposal for the LoggingOptions, so logging callback+logLevel would behave something like HttpTransport - you don't have to specify it, or use different transport, but if you want, it is overridable.
Go and instrument more code with logging? One person does it, or everyone does their part? Storage does not currently have logging at all. Let's also come up with pattern, which log levels we use. Create a separate work item for that?
Use atomic instead of mutex? I'm pretty sure no one would disagree, but what if would require us to not use
std::function
in the user-facing API? (Logging: use atomics instead of mutex #1638)(Just in case: #1568)
The text was updated successfully, but these errors were encountered: