[Feature Proposal] Information Board node type
Maintainer antworten meist innerhalb von 2 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
The proposal does not identify implementation files or tests. Start by reading the existing node type advert, ACL/admin, and article or message transfer code to understand where this feature would fit. Done means administrators can manage articles and users can browse and fetch versioned articles on demand, with caching, resumable transfers, and reboot behavior as described.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Idea
Add a new node type, Information Board, for persistent administrator-published notices that users can browse and fetch on demand.
Possible uses include community information, events, emergency notices, schedules, and service announcements.
How it would work
The main goal is to keep radio traffic low.
ADVERT
board_revision
↓
revision changed?
↓ yes
GET_INDEX
↓
ID + version + title
↓
user selects article
↓
GET_ARTICLE
The board does not push article bodies.
Clients cache articles locally and only fetch an article when its version differs from the cached version.
Example index:
137 v4 "Water shutoff Saturday"
136 v1 "Road work"
132 v7 "Meeting point changed"
If the client already has:
137 v4
136 v1
those articles require no radio traffic.
Advert
Suggested node type:
#define ADV_TYPE_INFO_BOARD 5
Advert contains a compact board revision:
ADV_TYPE_INFO_BOARD
name = "Community Info"
board_revision = uint16
Client logic:
same revision -> use cache
different revision -> fetch index
No long hashes need to be transmitted.
Wrapping versions
Both board revisions and article versions use:
1 ... 65535 -> 1
0 is reserved.
Clients only compare for equality, never > or <.
So this works naturally:
cached revision = 65535
advert revision = 1
different -> fetch index
Each article has:
article_id uint32
article_version uint16
Editing an article keeps its ID but increments its version.
Article transfer
When selected:
GET_ARTICLE
article_id
expected_version
offset
Including the version and offset makes transfers stateless and resumable.
If an article changes during transfer:
VERSION_CHANGED
current_version = ...
and the client restarts the download.
Index consistency
If the index is paginated, each page request includes the board revision.
If the board changes between pages:
INDEX_CHANGED
and the client restarts the index fetch.
Reboots
A normal reboot keeps:
board_revision
article_versions
article_ids
so clients do not see a false change.
A separate board_epoch can identify a factory reset/new database. If the epoch changes, clients discard the old board cache and fetch everything again.
Administration
Normal users have read access.
Administrators can:
CREATE_ARTICLE
UPDATE_ARTICLE
DELETE_ARTICLE
Ideally this would reuse existing MeshCore ACL/admin mechanisms.
Why this stays radio-efficient
Typical flow:
hear advert
revision unchanged
-> send nothing
revision changed
-> fetch compact index
most article versions still match cache
-> send nothing for those
user opens one changed article
-> fetch only that article
So traffic is mostly limited to compact metadata plus the specific content users actually request.
- Vorherrschende Sprache
- C
- Sterne
- 3.9k
- Forks
- 1.5k
- Ø Merge
- 2 T. 21 Std.
- Gemergte PRs (30 T.)
- 34
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus meshcore-dev/MeshCore
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
meshcore-dev/MeshCore#3781 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
meshcore-dev/MeshCore#3760 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
meshcore-dev/MeshCore#3698 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 63/100
meshcore-dev/MeshCore#3622 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
[Feature Request] Set Australia (Mid) Preset to automatically enable 2 byte default path hash sizeOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
meshcore-dev/MeshCore#3571 · 5 Reaktionen ·
Maintainer antworten meist innerhalb von 2 Tagen
Alle Issues in meshcore-dev/MeshCore
Ähnliche Issues
-
[yugabyted] xcluster set_up and add_to_replication fail for database names containing - . or (Offenkind/bug priority/medium qa_automation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
yugabyte/yugabyte-db#37324 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 80/100
ly05010419/MacNativeGames#1897 ·
Maintainer antworten meist innerhalb von 1 Tag
-
area: metrics area: tracing contribfest enhancement good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
open-telemetry/opentelemetry-ebpf-instrumentation#4188 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
FujiNetWIFI/fujinet-firmware#2328 ·
Maintainer antworten meist innerhalb von 1 Tag