Architecture suggestion: new “data sources” category

[dathbe]

This would be a larger architectural change for some later major release, but I’m curious to get people’s thoughts on splitting the current modules into two different sections: one for data sources and one for display modules.

The specific issue I’m trying to resolve is minimizing API calls. I have three weather modules (one for alerts, one for a rain map, and one for current weather and forecast). All three draw from OpenWeatherMap API, but none use the same notification name/structure. This results in 3x the API calls, when one should be sufficient.

I think an elegant (though course-changing) solution would be to have a set of data sources that would grab data and present them in notifications, so that the display modules can (should) draw from one or more to present the information in various formats.

This would also help users weed through the modules. Users could look for data sources they’re interested in and then be presented with a narrower list of modules that can display that data source.

And it would help developers by not making them recreate the wheel when a method for collecting the data they want to use.

Probably a pipe dream, but it was a thought I had.

[MarcLandis]

Like an hour ago I was thinking about the exact same approach and then I found this request. I absolutly support this.

[bugsounet]

maybe an idea,

• Define needs from other modules
• Format an object with data received from the weathers providers used with weather default module (need to create an MagicMirror weather object with max informations when calling weather API)
• send data in MagicMirror defined format with notification

---> modules can use it

We have coded +/- the same thing with calendar default module

[khassel]

the default weather module already sends notifications, I'm using the default weather module as data provider here.

[sdetweil]

calendar and weather broadcast their data
what else is there?

[dathbe]

calendar and weather broadcast their data
what else is there?

1. There are far more sources of data than calendar and weather.
2. There are far more sources of calendar and weather data than what is broadcast by the default calendar & weather modules.
3. Without explicit reference to the calendar and weather modules being data providers, with documentation of what they provide and in what format, other devs have to reverse engineer what those modules (or any other modules) are doing to repurpose it.

There are just two very different things that modules are doing: grabbing data; and displaying it. Various modules and devs have strengths in one or the other.

[sdetweil]

alert has no data
compliments data is visible in config
updatenotification no useful data

[dathbe]

The default modules are not the only sources of data.

[sdetweil]

oh, you want US to build and support a random storage database

[sdetweil]

@bugsounet
weather does all that already

[dathbe]

oh, you want US to build and support a random storage database

No, but thanks for the sarcasm.

[sdetweil]

@dathbe what other modules provide data that is duplicated by others?

ive been here 7 years and don't see a single other module content consumed by others. plenty of time to become a provider