-
-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to a plugin style approach to exposing models in CO2.js #206
Comments
@mrchrisadams I've typed this out as a stream of consciousness, so please let me know if its comprehendible. If this makes sense, I'd be looking to implement it alongside the upcoming SWD changes that are planned for the next release. That would be done without breaking existing functionality (i.e. there'd be two ways to call SWD) but then we'd update the documentation to point to this new way & eventually deprecate the old (current) way of working with models as we move to v1.0 later this year. |
This would also enable carbon estimation models to expose additional functions such as energy related calculations. This has been requested in #195 |
After some internal discussion, this has been deferred to a later release. In the meantime, this thread will be used to capture ideas/inspiration from other tools that have plugin architectures that we can learn from. Two examples:
|
Is your feature request related to a problem? Please describe.
The aim of the suggested changes described below is to enable the addition of more carbon estimation models to CO2.js in a way that is flexible for models that are not based on data transfer (bytes) as a key input
Currently, we have a number of modules as named exports which allow access to different functions and variables within CO2.js. For example, if you wanted to perform a carbon estimate you'd import the
co2
module as follows:This is, however, somewhat limiting in that any new models that are introduced CO2.js would need to conform to the existing functions that are in those models. Sticking with the example of estimating emissions, a new model would need to work within the bounds of the
perByte
orperVisit
functions. These functions take inputs ofbytes
andgreenHosting
. However, not all models use these inputs.Describe the solution you'd like
To allow for greater flexibility as other models are added to CO2.js, a change should be made towards a plugin style system. CO2.js could set some expected defaults, as in a function or output that it expects all models to exports, and then models can be free to use whatever inputs or data they need to behind the scenes.
For example, each model plugin could be expected to export a function called
estimate
. This would be the default function called when that model is used. Inputs can then be passed into the function via an options objects. The model can also then expose additional functions for specific cases if need be.Let's take the example of the Sustainable Web Design Model which is already implemented in CO2.js. It might look something like this:
If another model were to be added (let's say for example
onlineEventsModel
) then it would be expected to expose a defaultestimate
function, but then could also expose additional functions for specific cases (e.g.perVideoCall
,perConference
,perPodcast
etc.). These additional functions might build upon the functionality of theestimate
function or could be standalone.The text was updated successfully, but these errors were encountered: