From fddd65ddb8a4e492851478ba7fd31e26426a0722 Mon Sep 17 00:00:00 2001 From: Lars Corbijn Date: Wed, 22 May 2024 18:52:27 +0200 Subject: [PATCH] Update documentation links for typescript change (#633) --- docs/communication.md | 2 +- docs/config-system.md | 2 +- docs/devs/protocol.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/communication.md b/docs/communication.md index 077baa15..25eb5023 100644 --- a/docs/communication.md +++ b/docs/communication.md @@ -30,7 +30,7 @@ There's also the virtual connector which lets two links in the same program be c ## Message There's two types of messages currently implemented apart from the Link builtin close message and that's Request and Event. -The builtin messages are defined in [packages/lib/link/messages.js](/packages/lib/link/messages.js) and are attached to links via the attachAllMessages function, which is usally called in the Link subclass constructor. +The builtin messages are defined in [packages/lib/src/link/messages.ts](/packages/lib/src/link/messages.ts) and are attached to links via the attachAllMessages function, which is usally called in the Link subclass constructor. The messages define which links they are valid on and only attaches handlers for those links. There's also a forwarding mechanism for when a request or event is to be forwarded another hop. diff --git a/docs/config-system.md b/docs/config-system.md index e822e2b7..2d080c4a 100644 --- a/docs/config-system.md +++ b/docs/config-system.md @@ -6,7 +6,7 @@ Clusterio uses a field based configuration system to manage settings for the con Plugins can add their own config fields for the controller and instances configs. The fields are defined early in the startup, and fields for disabled plugins will still be created. -The built-in config fields are defined in [packages/lib/config/definitions.js](/packages/lib/config/definitions.js) while plugins can add their own config field definitions to the `controllerConfigFields` and `instanceConfigFields` properties of the `plugin` export. +The built-in config fields are defined in [packages/lib/src/config/definitions.ts](/packages/lib/src/config/definitions.ts) while plugins can add their own config field definitions to the `controllerConfigFields` and `instanceConfigFields` properties of the `plugin` export. A `.load_plugin` field is automatically created for each plugin and it's used to enable/disable the loading plugins on startup. diff --git a/docs/devs/protocol.md b/docs/devs/protocol.md index ea28005c..ae072857 100644 --- a/docs/devs/protocol.md +++ b/docs/devs/protocol.md @@ -1,7 +1,7 @@ # Protocol Clusterio communicates using a simple homebrew message passing protocol based on JSON over WebSocket with limited support for reliable transport of messages. -The protocol is implemented in [packages/lib/link](/packages/lib/link) and uses the `ws` library to handle the WebSocket connections on the Node.js side and the native WebSocket API on the browser side. +The protocol is implemented in [packages/lib/src/link](/packages/lib/src/link) and uses the `ws` library to handle the WebSocket connections on the Node.js side and the native WebSocket API on the browser side. Two general kinds of messages are supported: events and requests. Events are messages sent by one party and received by the other and offer no notification for the sender on whether it was actually received. @@ -166,7 +166,7 @@ Events are messages send in one direction over the link, that the receiver is ex By convention message types ending in `*_event` are events. The data payload of an event consists solely of event specific properties. -See [packages/lib/link/messages.js](/packages/lib/link/messages.js) for the recognized core events and their contents. +See [packages/lib/src/link/messages.ts](/packages/lib/src/link/messages.ts) for the recognized core events and their contents. Plugins may defined their own events as well. #### `*_event` @@ -181,7 +181,7 @@ They function a lot like HTTP requests except that both parties of a connection By convention message types ending in `*_request` are requests, and is expected to be replied to with a corresponding `*_response` message. If an error occured while processing the request an error response containing an error property in the data payload is sent instead. -See [packages/lib/link/messages.js](/packages/lib/link/messages.js) for the recognized core requests and their contents. +See [packages/lib/src/link/messages.ts](/packages/lib/src/link/messages.ts) for the recognized core requests and their contents. Plugins may define their own requests as well. #### `*_request`