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:
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.
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?
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`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
notplants
As mentioned in issue #45, we had a situation where the interface names (
wlan0andap0) 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)(replacesactivate_ap()&activate_client())add(wlan_iface: String, wifi: &WiFi)check_iface(wlan_iface: String, ap_iface: String)The
StartWlan0andStartAp0error variants have been collapsed into a singleStartInterfacevariant.These are breaking API changes and I will need to update
peach-weband 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.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?
I think it's best to call them from
peach-webdirectly. Otherwise we'll be making additional work for ourselves by having to add and maintainpeach-networkcalls inpeach-lib.