| David Martin / Wojciech Trocki - at it's most basic, my thinking is as follows: Metrics is it's own service and each service should be self contained and have it's own SDKs. My fear is that if we start bleeding metrics functionality into core, then the lines between what core is and what the service provides will become blurred. Re Core having to know about metrics - this will be the case whether the code is in core or not. Core will need to check if metrics is enabled before trying to send data, so it's either check the config each time to see if there are metrics service params defined, or (in the case of separate SDK) check if the metrics SDK module has been initialised - either way, a check will be required. From a testing perspective, I believe it will also be easier to test the metrics service in isolation if it has it's own SDK. As a potential compromise (and to address the concerns of interface injection and dependancy management), we could consider having a single static method on core that any service can call for attempting to log metrics. Core then checks if metrics is enabled and if so, hands of to that service to do the actual work. Finally, while the number & volume of metrics data being collected at the moment is quite small, I can see us adding more to this in the future, meaning that if we have the metrics code buried in core, we will be adding more and more service specific data to core. Re: "Metrics" vs "Statistics"
- "Metrics" - a system or standard of measurement
- "Statistics" - the practice or science of collecting and analysing numerical data in large quantities, especially for the purpose of inferring proportions in a whole from those in a representative sample.
It seems that neither name is ideal, but since statistics implies only numerical data and we are capturing more than just numbers, I don't think "Statistics" is a good/better name. Happy to discuss further and get additional points of view. I'm not (yet) convinced that metrics impl should be part of core, but am open to the possibility.... |