Skip to content

Break down the project #132

@peske

Description

@peske

Guyz, I strongly believe that it is the time to break the project down to smaller pieces. There are two "groups" of features that can (and should) be managed as a separate projects. The first group is made of mandatory parts that still can be isolated like:

  • ConcurrencyUtils
  • HdrHistogram
  • LibLog

The second group is made from optional parts:

  • ElasticSearch
  • InfluxDB
  • Graphite
  • Even Json

What I'm trying to say is that you should make something like:

  • Metrics.NET.Core
  • Metrics.NET.InfluxDB
  • Metrics.NET.ElasticSearch
  • etc.

Basically Metrics.NET.Core should be able only to report to console window; for additional reports one can pick the appropriate additional module.

There are few strong reasons for doing so:

  • The project will be much easier to manage, with clear boundaries;
  • Changing some optional feature (for example Metrics.NET.InfluxDB) will not cause changing version of the core. Basically if managed separately, an optional module would not prevent / slow down releasing the core module.
  • Any kind of a bug or poor implementation in one module (again for example in Metrics.NET.InfluxDB) will not influence the quality of the core;
  • Installed footprint would be smaller;
  • Some improvements (for example .NET Core version) would be easier to implement. You wouldn't have ensure that everything is portable - instead you can do this step by step (module by module)

Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions