gluon-status-page: rework package to not depend on batman

[christf]

This introduces a statuspage that works with babel.

Changes in the graphs have intentionally not been made. Reworking the stats should be left for after a merge of this PR.

[christf]

on irc it was discussed to not remove parts of the api. This PR will be reworked to reflect that.

[triplem]

Right now, I have browsed through those changes. I do have a couple of questions:

• Why are we not going to remove the "old" API? There any need to keep the old API?
• IMHO it would be appropriate to calculate all related datapoints in the backend and just transfer a single object (meaning for both currently available endpoints) the same data to the UI. The backend should decide which type of Protocol is used and not the UI.

@NeoRaider Could you please share your thoughts on this one?

[neocturne]

@triplem It must generally be expected that not all nodes are updated to a new Gluon version at once. The status page frontend allows to switch over to other nodes, so we try to keep both frontend and backend backwards compatible with at least the previous Gluon version.

Consolidating backend endpoints might be a good idea; I don't have a clear opinion on that as long as we don't have a concrete plan. Note that the status page is designed to make the backend as thin as possible (mostly just simple gluon-neighbour-info wrappers) and do all the heavy lifting in the frontend.

[triplem]

@NeoRaider I do understand (at least partly) the backwards compatibility issue. This means that the information should be retrieved via the same interface like in the old version.

The backend should provide the same information for both protocols (be it batman or babel) via the same backend, this will make the transition easy for the frontend part. No changes needed there except some slight adjustments to check protocol names.

In a future version I would then try to avoid to use the protocol name as a key in Json, this would make it easier to adapt to newer versions of protocols.

I do not understand the heavx lifting stuff. The backend knows whivh protocol it uses and should not delegate the responsibility to choose the correct endpoint based on this information to the ui. Dies not make any sense at all.

[neocturne]

The basic issue is that batman-adv and Babel simply don't provide the same information; this is the reason I'd like to keep the endpoints separate.

batman-adv has a single metric value called TQ, that an integer in the interval [0, 255], but is often scaled to [0, 1] (or [0%, 100%], and sometimes inverted; here, 255 is a perfect connection. Babel has separate RX and TX metrics, which are in the range [0, 65535]; in contrast to batman-adv, lower numbers are better.

With heavy lifting, I mainly referred to merging the information from different endpoints (in this case, WLAN metrics, routing protocol metrics and other neighbour information).

[christf]

this is still one stream called routingMetrics wihch is merged from a batadv and a babel stream.
I am not sure whether this already fulfills the requirement. Anyhow, I think I am done.

[christf]

rebasing the babel PR (with a working status page) on top of this one made me realize that there are some gaps between the two. let me figure out which patchset will need adjustments - it could be this one.

[christf]

this contains now the full patch set. rebasing on top of #1280 as discussed today....

[christf]

... I am still in the process of rebasing this, currently facing build-issues...

[christf]

this is not done yet :/ the data for a client is scattered across multiple lines

[christf]

The backend part has now been merged. Given the new infrastructure we have to see what Change we need now.

[christf]

much of this was done in #1366 the stream handling changed anyways. let's open a new PR for that one when we want to display babel metrics in addition to cfg80211 and when we want to link to neighbours on the status page.