📖 Small corrections, updates to the latest API, and grammar tweaks.
Motivation:
Make sure our README is current and easy to follow.
Modifications:
Graphite is a backend for metrics, Grafana is a frontend for visualization+alerting that can be powered by many backends.
We have a tagged release.
Add a link to @MrLotU 's SwiftPrometheus (emoji optional 😄 )
Some (mostly optional) punctuation tweaks
Tried to re-word the "applications choose their backend" section so it does not use the passive voice.
Update to the latest API... do we still want to write this out this here vs. link to the auto-generated API docs? 🤔 I'm leaning toward deleting it, but there's some value in it all being present here so long as we remember to update it.
Result:
Ideally, a better README! 📖
motivation: highlight the need to address overflow in metric objects that are integer based
changes:
* add section in the readme about addressing woverflow
* fix timer's unit conversion to address potential overflow
motivation: allow middleware libraries better control of metric object lifecycle to reduce potential memory footprint when using metrics libraries that use some kind of registry or cache (eg polling backends)
changes:
* Introduce metric.destroy() to enable lifecycle management
* Add destroy functions to example impl in readme
The bootstrap used to be invoked using `MyFactory.init` but nowadays we changed it to accepting an factory instance.
**Problem:**
- snippet was misleading and would not compile
**Solution:**
- change to snippet that will work with current shape of API
- make the code snippet more visible and not in-line, so it is easier to spot "so what do I need to do to bootstrap again...?"
* rename Counter::increment "value" parameter to "by"
motivation: nicer API signature
changes: rename Counter::increment and CounterHandler::increment "value" parameter to "by"
* prepare to release
motivation: the sswg voted to adopt the API. this is to prepare to a release
changes:
* rewrite readme
* add API docs
* add utilitiy scripts and docker setup for CI
* adjust linux tests
motivation: it's very beneficial for the protocols to use functions with concrete types because then there's no need for specialisation. At compile time, the compiler can often not know what concrete type will be used so it needs to create a 'generic at runtime' version of the function. If however all functions on the protocol do not use generics, there's no need for a 'generic at runtime' version of the function
changes:
* change CounterHandler::increment to take Int64 instead of <DataType: BinaryInteger>
* change RecorderHandler::record to take Int64 and Double instead of <DataType: BinaryInteger> and <DataType: BinaryFloatingPoint>
* adjust example and test implementation
* adjust docs
motivation: address feedback from community, prepare for moving api to official repo
changes:
* add reset method to counter
* do not force the user facing metric object to implement the mteric handler protocol. this was done for convinience and confuses matters
* adjust tests
* fix a few typos
Konrad `ktoso` Malawski
tomer doron
James Sherlock
Johannes Weiss
Joe Smith
Konrad `ktoso` Malawski
tomer doron
Cory Benfield