roadmap.md
# Future Roadmap
### Research Alternative Redis formats
- Look at alternative storage formats for Redis
- [redis bitmaps](http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps/)
- [redis bitfield](https://stackoverflow.com/questions/47100606/optimal-way-to-store-array-of-integers-in-redis-database)
- Add support for [zadd](http://redis.io/topics/data-types-intro) so one could determine single call versus multiple calls on a line, letting us determine the most executed code in production.
- Changes and updates to Ruby Coverage Library that helps support templates
- https://github.com/ioquatix/covered
- https://github.com/simplecov-ruby/simplecov/pull/1037
- Consider A Coverband Pro / Option to run coverband service locally
- review how humperdink / e70 track translations, particularly how humperdink uses dirty sets with redis, for perf improvements for trackers
- https://github.com/livingsocial/humperdink
- https://github.com/sergioisidoro/e7o/blob/master/lib/e7o.rb
- Possible Cross Application Support to track library usage?
- Reducing differences between coverband local and coverband service
### Coverband Next...
Will be the fully modern release that drops maintenance legacy support in favor of increased performance, ease of use, and maintainability.
- look at adding a DB tracker
- defaults to oneshot for coverage
- possibly splits coverage and all other covered modules
- drop middleware figure out a way to kick off background without middelware, possibly use similar process forking detection to humperdink
- https://github.com/livingsocial/humperdink/blob/master/lib/humperdink/fork_savvy_redis.rb
- options on reporting
- background reporting
- or middleware reporting
- Support for file versions
- md5 or release tags
- add coverage timerange support
- improved web reporting
- lists current config options
- eventually allow updating remote config
- full theming
- list redis data dump for debugging (refactor built in debug support)
- additional adapters: Memcache, S3, and ActiveRecord
- add articles / podcasts like prontos readme https://github.com/prontolabs/pronto
- add meta data information first seen last recorded to the coverage report views (per file / per method?).
- more details in this issue: https://github.com/danmayer/coverband/issues/118
- See if we can add support for views / templates
- using this technique https://github.com/ioquatix/covered
- Better default grouping (could use groups features for gems for rails controllers, models, lib, etc)
- Improved logging for easier debugging and development
- drop the verbose mode and better support standard logger levels
- redo the logger entirely
- redo config system and allow live config updates via webui
- move all code to work with relative paths leaving only stdlib Coverage working on full paths
# Out of Scope
It is important for a project to not only know what problems it is trying to solve, but what things are out of scope. We will start to try to document that here:
* We have in the past tried to add coverage tracking for all gems, this added a lot of complexity and computation overhead and slowed things down to much. It also was of less value than we had hoped. There are alternative ways to instrument a shared library to track across multiple applications, and single application gem utilization is easier to handle in a one of basis. It is unlikely we will support that again.