Removed hardcoded interfaces from peach-network #47

glyph · 2021-12-14T19:07:21Z

glyph commented

2021-12-14 19:07:21 +00:00

As mentioned in issue #45, we had a situation where the interface names (wlan0 and ap0) were hardcoded in several functions. This PR replaces those hardcoded values with argument-derived equivalents.

Changes have been made to the following functions:

start_iface_service(iface: String) (replaces activate_ap() & activate_client())
add(wlan_iface: String, wifi: &WiFi)
check_iface(wlan_iface: String, ap_iface: String)

The StartWlan0 and StartAp0 error variants have been collapsed into a single StartInterface variant.

These are breaking API changes and I will need to update peach-web and the physical menu system accordingly.

I like the flexibility this change offers (especially in the context of PeachPub where the deployment environment is unlikely to have the full suite of PeachCloud configuration in place). I'm imagining the ability to define the interfaces in the main Peach config toml (maybe wireless, access point and ethernet - with all being optional). Then we can still display some network-related stats in the UI for PeachPub, even if the AP <-> client switching functionality isn't available.

As mentioned in [issue #45](https://git.coopcloud.tech/PeachCloud/peach-workspace/issues/45), we had a situation where the interface names (`wlan0` and `ap0`) were hardcoded in several functions. This PR replaces those hardcoded values with argument-derived equivalents. Changes have been made to the following functions: - `start_iface_service(iface: String)` (replaces `activate_ap()` & `activate_client()`) - `add(wlan_iface: String, wifi: &WiFi)` - `check_iface(wlan_iface: String, ap_iface: String)` The `StartWlan0` and `StartAp0` error variants have been collapsed into a single `StartInterface` variant. These are breaking API changes and I will need to update `peach-web` and the physical menu system accordingly. I like the flexibility this change offers (especially in the context of PeachPub where the deployment environment is unlikely to have the full suite of PeachCloud configuration in place). I'm imagining the ability to define the interfaces in the main Peach config `toml` (maybe wireless, access point and ethernet - with all being optional). Then we can still display some network-related stats in the UI for PeachPub, even if the AP <-> client switching functionality isn't available.

glyph added 1 commit 2021-12-14 19:07:22 +00:00

7fe4715014 bump version and switch to rust 2021

glyph requested review from notplants 2021-12-14 19:07:29 +00:00

glyph added the

maintenance

label 2021-12-14 19:07:48 +00:00

notplants commented

2021-12-14 19:23:39 +00:00

nice. I wouldn't hold ourselves to making sure all networking functionality works in all situations (sounds like an infininite task), but as you suggest being able to show some status info sounds more doable and cool that we could make it more flexible if needed... or to some future contributor who really wants to make peachcloud work in a specific environment

by the way, was wondering, now that peach-network and other services are not exposed via jsonrpc, do you still plan to call them from peach-web by calling functions in peach-lib? or just to call the functions from peach-network in peach-web directly?

nice. I wouldn't hold ourselves to making sure all networking functionality works in all situations (sounds like an infininite task), but as you suggest being able to show some status info sounds more doable and cool that we could make it more flexible if needed... or to some future contributor who really wants to make peachcloud work in a specific environment by the way, was wondering, now that peach-network and other services are not exposed via jsonrpc, do you still plan to call them from peach-web by calling functions in peach-lib? or just to call the functions from peach-network in peach-web directly?

👍 1

glyph commented

2021-12-14 20:08:12 +00:00

do you still plan to call them from peach-web by calling functions in peach-lib? or just to call the functions from peach-network in peach-web directly?

I think it's best to call them from peach-web directly. Otherwise we'll be making additional work for ourselves by having to add and maintain peach-network calls in peach-lib.

> do you still plan to call them from peach-web by calling functions in peach-lib? or just to call the functions from peach-network in peach-web directly? I think it's best to call them from `peach-web` directly. Otherwise we'll be making additional work for ourselves by having to add and maintain `peach-network` calls in `peach-lib`.

👍 1

glyph merged commit b5ce677a5b into main

2021-12-14 20:42:40 +00:00

glyph deleted branch iface_agnostic

2021-12-14 20:42:40 +00:00

glyph referenced this issue from a commit

2021-12-14 20:42:41 +00:00

Merge pull request 'Removed hardcoded interfaces from peach-network' (#47) from iface_agnostic into main

glyph referenced this pull request

2021-12-15 13:18:01 +00:00

Make peach-network functions interface-agnostic #45

Sign in to join this conversation.