docs: refine operation interfaces and batching
This commit is contained in:
+12
-9
@@ -10,7 +10,7 @@ WIP上の主要な登場主体は**Client**と**Host**である。
|
||||
|
||||
ClientはHostが提供するWorldspaceをユーザーまたはAIへ提示する。
|
||||
|
||||
Hostから取得したエントリを既知の空間として保持・キャッシュし、`ref`によるObject同一性の追跡や、観測時と操作時の対応関係の検証を行う。
|
||||
Hostから取得したエントリとInterface定義を既知の空間として保持・キャッシュし、`ref`によるObject同一性の追跡や、観測時と操作時の対応関係の検証を行う。
|
||||
|
||||
GUI、AI用Tools、PTC / REPL向けAPIなどへの投影はClient実装の責務とする。
|
||||
|
||||
@@ -18,7 +18,7 @@ GUI、AI用Tools、PTC / REPL向けAPIなどへの投影はClient実装の責務
|
||||
|
||||
HostはClientに対して一つのWorldspaceを提供する。
|
||||
|
||||
どのObject、エントリ、Operation、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
|
||||
どのObject、エントリ、Interface、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
|
||||
|
||||
Host内部でGitHub API、Database、Filesystem、RAG、他Agent、別プロトコルなどをどう接続・集約するかはWIPの規定対象外とする。
|
||||
|
||||
@@ -32,13 +32,14 @@ ClientとHostの境界は通信境界であると同時に、ある主体へど
|
||||
|
||||
## 3.3 基本操作
|
||||
|
||||
現時点では次の3操作をCore Protocolの基本とする。
|
||||
現時点では次の4操作をCore Protocolの基本とする。
|
||||
|
||||
- `fetch(entry)` — 1つのエントリにあるObjectの公開情報を取得する。
|
||||
- `fetch(entry)` — 1つのエントリにあるObjectの公開情報とInterface参照を取得する。
|
||||
- `fetch_tree(entry, depth, limit)` — 指定エントリを起点に、indexableな子エントリを幅優先探索してエントリツリーとして取得する。
|
||||
- `call_operation(target, operation, input)` — Objectが公開するOperationを実行する。
|
||||
- `fetch_interface(interface)` — Interface参照からWIP IDL documentを取得する。
|
||||
- `call_operation(target, operation, arguments)` — Objectが参照するInterfaceに宣言されたOperationを実行する。
|
||||
|
||||
Operationのinterfaceは[WIP IDL](draft/wip-idl.md)で定義する。`call_operation`の`input`はOperationが宣言したinput recordに従う名前付きの型付き値であり、引数がない場合も空のrecordを渡す。Core Protocolはこの値をJSONに限定せず、transport bindingが具体的なencodingを定める。
|
||||
Interfaceの定義は[WIP IDL](draft/wip-idl.md) documentそのものであり、そこに宣言された関数の集合がOperation一覧となる。`call_operation`の`arguments`は選択したOperationのparameter listに従う名前付きの型付き値であり、引数がない場合は空のrecordとする。Core Protocolはこの値をJSONに限定せず、Transport Bindingが具体的なencodingを定める。
|
||||
|
||||
## 3.4 `fetch_tree`
|
||||
|
||||
@@ -52,13 +53,15 @@ Operationのinterfaceは[WIP IDL](draft/wip-idl.md)で定義する。`call_opera
|
||||
|
||||
## 3.5 Operation実行と発見
|
||||
|
||||
`call_operation`の結果はOperationのWIP IDL output型に従う型付き値である。Output schema上で`entry`として宣言された位置には、同じWorldspace内のエントリを指すcanonical absolute pathを返せる。
|
||||
`call_operation`の結果は、選択したOperationのWIP IDL return typeに従う型付き値である。Return type上で`entry`として宣言された位置には、同じWorldspace内のエントリを指すcanonical absolute pathを返せる。
|
||||
|
||||
Clientはoutput schemaに従って`entry`型の位置を認識する。通常の`string`や任意JSONに含まれるpathらしい文字列を、エントリとして推測してはならない。
|
||||
Clientはreturn typeに従って`entry`型の位置を認識する。通常の`string`や任意JSONに含まれるpathらしい文字列を、エントリとして推測してはならない。
|
||||
|
||||
返されたエントリpathのTree上の位置はOperationの実行対象から独立しており、実行対象の子に限定されない。Operationの実行対象と返されたエントリの間に、暗黙の親子関係や意味的関係を作ってはならない。
|
||||
|
||||
ClientはOperation結果として発見したpathを一時的に扱い、必要なものを`fetch`または`fetch_tree`して既知の空間へ統合できる。複数pathに対する`fetch`は意味上それぞれ独立しており、Transport Bindingは同じ意味を保ったまま一つのrequestへbatchしてよい。
|
||||
ClientはOperation結果として発見したpathを一時的に扱い、必要なものを`fetch`または`fetch_tree`して既知の空間へ統合できる。
|
||||
|
||||
複数の`fetch`または`fetch_interface`は、Core Protocol上ではそれぞれ独立した操作である。Transport Bindingは、個別に実行した場合と同じ意味を保ったまま、Clientが選択した複数の操作を一つのrequestへbatchしてよい。HostがClientの既知状態を推測して追加情報を先行同梱することはCore Protocolの一部としない。
|
||||
|
||||
## 3.6 Transportとの分離
|
||||
|
||||
|
||||
Reference in New Issue
Block a user