Closed javierbrk closed 7 months ago
This looks good :D
Do you think we should include it in the next release candidate once it is merged?
Do you plan to move all this to OpenWrt repositories at some point?
Do you think we should include it in the next release candidate once it is merged?
imo should be included! This makes the shared state calls more consistent...
But, it will break the compatibility with older versions. Are this packages already included on the actual version?
Do you plan to move all this to OpenWrt repositories at some point?
I think shared state not exists on the OWRT repos no?
Do you think we should include it in the next release candidate once it is merged?
imo should be included! This makes the shared state calls more consistent...
But, it will break the compatibility with older versions. Are this packages already included on the actual version?
Compatibility? Currently we have the latest stable release 2020.4 based on OpenWrt 19.07 and including LibreMesh code from more than one year ago. Most importantly, it has the legacy non-async shared-state. So the compatibility with this one I feel is not going to be preserved anyway, no?
Do you plan to move all this to OpenWrt repositories at some point?
I think shared state not exists on the OWRT repos no?
Shared state does not exist on OpenWrt repository, correct. But it should be there. It should not be here. In case there is any shared-state developer willing to manage the migration, maybe some people from OpenWrt could help...? @aparcar
@ilario shared-state developers and it is pretty tied to libre-mesh stuff altought it might be used indipendently, at this stage of development, moving it to openwrt repository could be premature IMHO, but once shared-state-async is more stable and completely substitute shared-state Lua, it might be good to move it in openwrt-packages
Shared State rpcd/ubus interface is used only by lime app so they go together. The last release of limeapp is not using this interface. @selankon can confirm. So this is not required in the candidate release.
Ubus interface for shared state
current implementations of rpcd for shared-state are inconsistent this new implementation adds a consistent format across the three implementations (shared-state, shared-state-async, shared-state-multiwriter ) In every case calls to shared state get or sync will return a json object wit this format
Also this new implementation for shared-state-async uses a shell script to simplify the implementation
Ubus interface for shared state async
ubus -S call shared-state-async get '{"data_type": "bat-hosts"}'
ubus -S call shared-state-async get '{"data_type": "bat-hosss"}'
ubus -S call shared-state-async sync '{"data_type": "bat-hosts"}'
ubus -S call shared-state-async sync '{"data_type": "bat-hosss"}'
ubus -S call shared-state-async sync '{"data_type": "bat-hostss", "peers_ip":"10.13.30.20"}'
ubus -S call shared-state-async sync '{"data_type": "bat-hosts", "peers_ip":"10.13.30.20"}'
ubus -S call shared-state-async sync '{"data_type": "bat-hosts", "peers_ip":"127.0.0.1"}'
Ubus interface for shared state and shared state Multiwriter
Get the list of available methods using:
ubus -v list shared-state
Get wifi links information:
ubus -S call shared-state getFromSharedState '{"data_type": "wifi_links_info" }'
Write information that is common to every all the network:
ubus -S call shared-state insertIntoSharedStateMultiWriter '{"data_type": "ref_state_wifi_links", "json": {"primero":{"bleachTTL":27}}}'
Get the information in the same node:
ubus -S call shared-state getFromSharedStateMultiWriter '{"data_type": "ref_state_wifi_links"}'
Get the info in another node, before getting the information the others need to sync on the same topic. This has to be done before reading and data types usually do it in a cron job.
shared-state-multiwriter sync ref_state_wifi_links
ubus -S call shared-state getFromSharedStateMultiWriter '{"data_type": "ref_state_wifi_links" }'