Currently, the models available in CO2.js are frontend focused, with a bias towards estimating website carbon emissions. We would like to see additional models that can be used for other areas of digital emissions estimation added to CO2.js.
One area that we believe could benefit from this is the estimation of server-side emissions. We believe that having a simple implementation that can estimate the emissions of running some code on a server would be extremely useful for developers. We have seen some implementations of this in other languages. Most of the libraries listed in the recent GitHub blog post on sustainable software tools do this in some way.
This issue is to discuss what an implementation might look like in CO2.js. It might be a lite version of Cloud Carbon Footprint, or some other existing methodology. It might be a wrapper around some other tooling or library that we can include as a dependancy. It might simply be a reference model that takes some basic inputs (e.g. server model, usage duration, used capacity) and returns a result - this again would have to be based on some existing model.
This work would tie in closely with making CO2.js extensible by converting it to a plugin-based architecture as outlined in #206.
Currently, the models available in CO2.js are frontend focused, with a bias towards estimating website carbon emissions. We would like to see additional models that can be used for other areas of digital emissions estimation added to CO2.js.
One area that we believe could benefit from this is the estimation of server-side emissions. We believe that having a simple implementation that can estimate the emissions of running some code on a server would be extremely useful for developers. We have seen some implementations of this in other languages. Most of the libraries listed in the recent GitHub blog post on sustainable software tools do this in some way.
This issue is to discuss what an implementation might look like in CO2.js. It might be a lite version of Cloud Carbon Footprint, or some other existing methodology. It might be a wrapper around some other tooling or library that we can include as a dependancy. It might simply be a reference model that takes some basic inputs (e.g. server model, usage duration, used capacity) and returns a result - this again would have to be based on some existing model.
This work would tie in closely with making CO2.js extensible by converting it to a plugin-based architecture as outlined in #206.