Skip to content
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

direct upload of nodes JSON-data #11

Closed
SvenRoederer opened this issue Dec 7, 2020 · 4 comments
Closed

direct upload of nodes JSON-data #11

SvenRoederer opened this issue Dec 7, 2020 · 4 comments

Comments

@SvenRoederer
Copy link
Contributor

SvenRoederer commented Dec 7, 2020

Even hopglass was intentionally planned as an additional map to OWM, it has now become the main-map for us as OWM has died.

Currently the node-data gets uploaded to the utils.berlin.freifunk.net server which has forwarded them to OWM and hopglass. As currently no (full-featured) alternative to the former OWM seems on the way, I wonder:

Should we think of a more effective way to handle this data?

I'm asking, because I found some things in the owm-client, which makes me think of rewriting / replacing the whole tool.

@sarumpaet
Copy link
Contributor

My plan was to write a proper replacement for the OWM backend in Python+Postgres at some point.

The current "backend" is just a small PHP script that dumps the incoming OWM JSON data to disk to be read by the Hopglass converter later. It doesn't provide any query endpoints (that the old OWM backend provided), so some functionality on the website and in the wiki doesn't work anymore.

However, writing that new backend should be about one day of work, and we need it anyway as replacing the whole thing won't make all those OWM client nodes go away (and might well introduce another API that will be legacy at some point).

@SvenRoederer
Copy link
Contributor Author

SvenRoederer commented Dec 20, 2020

My plan was to write a proper replacement for the OWM backend in Python+Postgres at some point.

"plan was" or "plan is"?

However, writing that new backend should be about one day of work, and we need it anyway as replacing the whole thing won't make all those OWM client nodes go away (and might well introduce another API that will be legacy at some point).

A good argument for staying with the current JSON-API for publishing the data we currently do already (generic node data) and probably do more processing on the server-side.


One part of the "some things in the owm-client" was the idea of integrating the node-monitoring (see freifunk-berlin/firmware#819 (comment)). For this I send a request for comments to the Mailinglist (https://lists.berlin.freifunk.net/pipermail/berlin/2020-December/051852.html)

@sarumpaet
Copy link
Contributor

sarumpaet commented Jan 11, 2021

"plan was" or "plan is"?

Good question! I don't really know. If someone else wants to help with it or do it altogether, go at it.

@sarumpaet
Copy link
Contributor

OWM is back: 898e517

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants