osFoundry / Platform
Echtzeit-Datenkanäle
Pub/Sub-Kanäle mit At-Least-Once-Zustellung, Verlaufswiedergabe und Cursor pro Abonnent.
Was es ist
Echtzeit-Datenkanäle sind das Messaging-Rückgrat von osFoundry, um Ereignisse zwischen den beweglichen Teilen deines Workspace zu transportieren. Jeder Produzent (ein Agent, eine laufende App, ein Code-Prozess oder ein Chat) veröffentlicht Nachrichten in einem benannten Kanal, und jeder Abonnent dieses Kanals erhält sie. Es ist das klassische Publish/Subscribe-Modell: Produzenten und Konsumenten sind entkoppelt, du kannst also Abonnenten hinzufügen oder entfernen, ohne den veröffentlichenden Code anzurühren, und ein einzelnes Ereignis kann sich gleichzeitig an viele Leser verteilen.
Die Zustellung erfolgt mindestens einmal (at-least-once). Eine bereits veröffentlichte Nachricht erreicht jeden Abonnenten auch über Reconnects und Neustarts hinweg, mit dem Kompromiss, dass ein Abonnent dieselbe Nachricht gelegentlich zweimal sehen kann. Konsumenten sollten ihre Handler daher als idempotent behandeln (Arbeit über eine Message-ID schlüsseln oder auf einem natürlichen Schlüssel deduplizieren). Kanäle bewahren die History, statt eine Nachricht sofort nach dem Lesen zu verwerfen, was zwei Dinge ermöglicht: Replay, bei dem ein Abonnent vergangene Nachrichten aus dem Kanal erneut lesen kann, statt nur das live Eintreffende zu sehen, und Cursor pro Abonnent, bei denen jeder Abonnent seine eigene Position unabhängig verfolgt. Ein Cursor bedeutet, dass ein Abonnent, der zurückfällt, die Verbindung verliert oder später startet, genau dort weitermacht, wo er aufgehört hat, und zwei Abonnenten desselben Kanals können an völlig unterschiedlichen Punkten des Streams sitzen, ohne sich gegenseitig zu stören.
Weil osFoundry ein Bring-your-own-Key-, Local-first-Desktop-Workspace ist, läuft diese Datenebene neben deiner Arbeit, statt über einen fremden Message-Broker zu führen, den du bereitstellen und pro Sitz bezahlen müsstest. Kanäle sind die Verrohrung unter Funktionen, die auf Veränderung reagieren müssen, sobald sie geschieht: ein Agent, der auf neue zu verarbeitende Elemente achtet, eine App, die sich in dem Moment aktualisiert, in dem Upstream-Daten eintreffen, oder eine Pipeline, in der eine Stufe an die nächste übergibt. Und sie lassen diese Teile ohne Polling und ohne enge Kopplung kommunizieren, während deine Daten auf deinem Gerät bleiben können.
Wichtige Funktionen
- Pub/Sub-Kanäle entkoppeln Produzenten von Konsumenten, sodass sich ein veröffentlichtes Ereignis an jeden Abonnenten verteilt, ohne den Publisher-Code zu ändern
- At-least-once-Zustellung lässt Nachrichten Reconnects und Neustarts überstehen; gestalte Konsumenten idempotent, da eine Nachricht gelegentlich erneut ankommen kann
- History-Replay erlaubt einem Abonnenten, vergangene Nachrichten erneut zu lesen, statt nur den Live-Verkehr zu erwischen, nützlich für Spätzugänge und Neuverarbeitung
- Cursor pro Abonnent verfolgen die Position jedes Lesers unabhängig, sodass ein langsamer, neu gestarteter oder spät hinzugekommener Abonnent genau dort weitermacht, wo er aufhörte
- Verbindet Agenten, Apps, Code und Chats über eine gemeinsame Local-first-Datenebene, ohne externen Broker zum Bereitstellen und ohne Gebühren pro Sitz
Anwendungsfälle
- Agent-Ersteller: Ein Agent abonniert einen Kanal eingehender Aufgaben und verarbeitet jede einzelne, macht nach einem Neustart von seinem Cursor aus weiter, ohne Arbeit zu verlieren oder erneut zu verarbeiten
- App-Entwickler: Eine Workspace-App abonniert einen Kanal und aktualisiert ihre Ansicht in dem Moment, in dem Upstream-Daten veröffentlicht werden, statt per Timer zu pollen
- Pipeline-Autor: Stufe eins veröffentlicht Ergebnisse in einem Kanal, den Stufe zwei konsumiert, mit verfügbarem Replay, um die History nach einer Logikänderung neu zu verarbeiten
Häufig gestellte Fragen
Was bedeutet At-least-once-Zustellung für meinen Code?
Sie garantiert, dass eine veröffentlichte Nachricht jeden Abonnenten auch über Verbindungsabbrüche und Neustarts hinweg erreicht, aber ein Abonnent kann dieselbe Nachricht gelegentlich mehr als einmal empfangen. Mach deine Handler idempotent (dedupliziere auf einer Message-ID oder einem natürlichen Schlüssel), damit eine Wiederholung harmlos ist und nicht doppelt zählt.
Kann ein neuer oder neu gestarteter Abonnent verpasste Nachrichten nachholen?
Ja. Kanäle behalten die History, und jeder Abonnent hat seinen eigenen Cursor, sodass ein spät hinzukommender oder nach einem Neustart zurückkehrender Abonnent vergangene Nachrichten erneut abspielen und von seiner zuletzt festgehaltenen Position weitermachen kann, statt nur den Verkehr zu sehen, der während der Verbindung eintrifft.
Teilen sich zwei Abonnenten desselben Kanals eine Position im Stream?
Nein. Cursor gelten pro Abonnent, sodass jeder Leser unabhängig voranschreitet. Ein Abonnent kann bei der neuesten Nachricht angekommen sein, während ein anderer im selben Kanal noch ältere History abarbeitet, und keiner beeinflusst den anderen.