@frockbot/computer-host-protocol 0.3.50 → 0.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/protocol.ts +11 -11
package/package.json
CHANGED
package/src/protocol.ts
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* The versioned wire protocol between a Bot Durable Object and the shared
|
|
3
|
-
* Computer host
|
|
3
|
+
* Computer host.
|
|
4
4
|
*
|
|
5
5
|
* "Cross-runtime communication uses narrow, versioned DTOs, and every inbound
|
|
6
6
|
* value is decoded at its seam." Both sides of the seam import this module and
|
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
*
|
|
11
11
|
* Every request carries the same envelope — `version`, the `effectId` the Bot
|
|
12
12
|
* Durable Object recorded before it called, the `identity` whose Computer this
|
|
13
|
-
* is (
|
|
13
|
+
* is (a Computer is keyed by User and by nothing else), the `tenant`
|
|
14
14
|
* Bot making the call, and an opaque `credentialRef`. The reference is
|
|
15
15
|
* resolved on the host and never carries credential material: "Secrets remain
|
|
16
16
|
* server-side and cross interfaces only as opaque references when necessary."
|
|
@@ -163,8 +163,8 @@ export type ComputerHostControlActionV1 = "acquire" | "renew" | "release";
|
|
|
163
163
|
* tenant's own desktop slot. `desktop-gui` is User-wide — one Computer serves
|
|
164
164
|
* all of a User's Bots and there is one screen on it, so a lease that
|
|
165
165
|
* serializes GUI work has to be held against the box, not against a tenant
|
|
166
|
-
* directory
|
|
167
|
-
*
|
|
166
|
+
* directory: for `computerUse`, only one may run at a time because the screen
|
|
167
|
+
* is shared.
|
|
168
168
|
*/
|
|
169
169
|
export type ComputerHostControlScopeV1 = "bot" | "desktop-gui";
|
|
170
170
|
|
|
@@ -250,10 +250,10 @@ export function computerHostOperationKindV1(
|
|
|
250
250
|
/**
|
|
251
251
|
* How far provisioning a cold Computer got, and how it ended.
|
|
252
252
|
*
|
|
253
|
-
* Provisioning a Computer installs a desktop stack and is quiet for minutes
|
|
254
|
-
*
|
|
255
|
-
*
|
|
256
|
-
*
|
|
253
|
+
* Provisioning a Computer installs a desktop stack and is quiet for minutes,
|
|
254
|
+
* so the phase is on the wire: a client that would otherwise show nothing at
|
|
255
|
+
* all can say "installing the desktop packages (2/5)", and a failure names the
|
|
256
|
+
* phase it failed in rather than the whole install.
|
|
257
257
|
*/
|
|
258
258
|
export interface ComputerHostProvisioningV1 {
|
|
259
259
|
/** Whether this run creates a Computer or updates its runtime in place. */
|
|
@@ -1341,9 +1341,9 @@ export function decodeComputerHostExecFrameV1(
|
|
|
1341
1341
|
|
|
1342
1342
|
/**
|
|
1343
1343
|
* Reassembles NDJSON frames from a byte stream whose chunk boundaries mean
|
|
1344
|
-
* nothing. This is the lesson of the framing incident
|
|
1345
|
-
*
|
|
1346
|
-
*
|
|
1344
|
+
* nothing. This is the lesson of the framing incident: a transport may split
|
|
1345
|
+
* or coalesce anywhere, so a frame boundary is the newline this decoder finds
|
|
1346
|
+
* and never the chunk the transport delivered.
|
|
1347
1347
|
*/
|
|
1348
1348
|
class ComputerHostFrameReaderV1<Frame> {
|
|
1349
1349
|
private buffer = "";
|