Sync
SyncClient
enables interacting with managed documents - MeshDocument
and synchronizing local changes with all remote clients.
Overview
MeshDocuments enable your agents to share and synchronize information in real time across platforms. They resemble a web page’s structure but offer much greater flexibility. For example, if you want to generate website content with your agents, you can start with a simple HTML-compatible document format:
A MeshDocument, like an HTML document, is composed of elements that can have child elements and attributes. However, MeshDocuments introduce additional features and capabilities that go beyond standard HTML or XML.
Defining Your Document Structure
To define the structure of a MeshDocument, you start by creating a schema using the MeshSchema class. A schema:
- Documents the structure of your MeshDocument for anyone in your organization.
- Ensures agents and users don’t write invalid data to the document.
- Allows agents to automatically generate, manipulate, and validate structured documents.
- Automatically generates LLM-compatible schemas for structured outputs.
- Synchronizes documents across all platforms that MeshAgent supports.
Similar to how a web page is structured, a MeshSchema begins with a root element that includes an allowed tag name and optional attributes. Afterward, you can define additional tags, their attributes, and the types of child nodes they can contain.
Example Schema
Suppose you have a basic web page structure and want to define a schema for it.
Many LLMs (such as OpenAI) and agent frameworks (such as MeshAgent) support JSON Schemas for defining inputs and outputs. Generating an OpenAI-compatible JSON schema from your MeshSchema requires only one line of code:
Creating a MeshDocument
To create a MeshDocument based on your schema and enable synchronization across different clients, use the MeshAgent runtime:
API Methods
Below is an example of how you might use the SyncClient
in your code:
SyncClient
The SyncClient
class is responsible for coordinating document synchronization through a RoomClient
. It automatically listens for local changes on MeshDocument
instances and forwards them to the remote server, while also applying remote changes as they are received.
room: RoomClient
An instance ofRoomClient
, which handles the underlying communication with the server.
create(path, json?)
- Parameters:
path
– The path where the document will be created on the server.schema
– AMeshSchema
describing the structure of the document.json
– (Optional) Initial data or metadata to send along with the creation request.
- Description
Sends a request to create a newMeshDocument
at the given path with a specified schema.
open(path, create = true)
- Parameters:
path
– The path identifying the document to open.create
– (Optional) Whether to create the document if it doesn’t exist. Defaults totrue
.
- Returns
AMeshDocument
instance tied to the specified path. - Description
Sends a request to connect to (and possibly create) the document at the given path. If successful, returns a reference-countedMeshDocument
that automatically sends local changes to the backend.
close(path)
- Parameters:
path
– The path of the document to close.
- Description
Decrements the internal reference count for the document. If it reaches zero, the document is unregistered locally, and a request is sent to the server to disconnect. No further changes will be synced once closed.
sync(path, data)
- Parameters:
path
– The path of the document to synchronize.data
– AUint8Array
(or equivalent) containing serialized changes.
- Description
Immediately sends sync data to the server. This method is useful if you have already encoded your changes and want to bypass the typical queued flow.
Additional Notes
-
Synchronized Changes
Once a document is opened, any local changes you make in the associatedMeshDocument
are automatically queued for sending, thanks tosendChangesToBackend
. You rarely need to callsync()
manually unless you want to send raw data yourself. -
Reference Counting
TheSyncClient
internally tracks how many times a document is opened via the same path. Callingopen
multiple times for the same path returns the same underlying document. Only when all references are closed (viaclose()
) will the client actually disconnect. -
Error Handling
If a request fails, theRoomClient
may throw an error (likeRoomServerException
). Wrap calls intry/catch
(or use.catch(...)
) to handle them gracefully. -
Concurrency and Performance
- For high throughput, ensure that your
RoomClient
and server are configured for concurrent operations. - The
SyncClient
uses aStreamController
internally to manage queued updates, sending them asynchronously to the server.
- For high throughput, ensure that your
-
Extensibility
You can extend theSyncClient
for specialized document operations—such as partial updates, conflict resolution logic, or customized schema handling—by adding new methods or composing it with other classes that also useRoomClient
.
Was this page helpful?