Hare/wip-reference

Fork 0

Files

T

Hare f6905074b1 docs: rewrite reference and clarify interface abstraction

2026-10-15 17:53:48 +09:00

30 KiB

Raw Permalink Blame History

Dynamic Worldspace Projection

Status

動的なWorldspaceを運用するには、Hostが何を解決し、どの範囲のObjectを投影し、どうOperationを実行するかを整理する必要がある。このdraftは、Rust / TypeScript Host APIの設計に先立って、その責務、処理モデル、要件をまとめたものである。

具体的なtrait、class、function、decorator、macro、builderのsyntaxは、ここでは定義しない。Projection Provider、Projection Resolution、Projected Object等もHost内部の設計を検討するためのworking terminologyであり、canonicalなProtocol typeではない。

Protocol上の確定事項はCore Model、Object tree / Schema、Operation and Interface、Protocolに従う。言語別のconceptual API modelはRust API ModelとTypeScript API Modelで扱う。

目的

WIP Hostは、事前に列挙した静的endpointだけでなく、実行時に存在と状態が決まる空間をWorldspaceへ投影できなければならない。Filesystem、database row、repository内容、検索結果、外部service上のentityなどが、その実装対象になる。

そのために、すべてのObjectを常駐instanceとして保持する必要はない。Backend dataをrequest時に解決し、必要な範囲だけObjectとして投影できることを基本とする。

固定pathに登録するObjectやservice endpointも、同じ動的projection modelで表現できるべきである。この場合はrouting / resolution structureが固定されているが、返すObject representationやvalidatorは、現在の主体やbackend stateに応じて変化してよい。静的登録を基本形にして大量のObject登録で動的空間を模倣するのではなく、動的な解決の特殊ケースとして静的登録を扱う。

基本的な分離

Host実装APIでは、少なくとも次の責務を区別する必要がある。ただし、責務ごとに一つのpublic type、trait、objectを設けるかどうかは未決定である。

Interface Declaration

Interface Declarationは、Operation名、parameter、return type、documentation等の宣言である。その宣言からInterface Descriptor、Value codec、boundary validationを生成する。

多数のObjectが共有できる、比較的静的なcapability schemaとして扱う。Objectの列挙とbackend dataのlifecycleは、Interface Declarationの責務には含めない。

Worldspace Projection

Worldspace Projectionは、Clientから受け取ったpathを現在の主体とbackend stateに基づいて解決し、Protocol上のObject projectionを生成する処理である。投影するObjectは、Host固有のentityを持たないvirtual nodeでも、一つのbackend entityに対応するものでも、複数のbackend entityを集約したものでもよい。

Projectionで決定する内容には、少なくとも次が含まれる。

そのpathのObjectを現在の主体へ公開するか。
公開するname、optionalなdescription、ref、validator。
Objectのinterfaces fieldへ設定するInterface参照のordered set。
observeから列挙可能なindexable children。
Operation実行時に現在のProjected Objectへ作用するために、Host内部で何を再解決または確立する必要があるか。

Host Runtime

Host RuntimeはProtocol requestを受け取り、ProjectionとInterface registryを協調させる。Operation callでは、現在のProjected Objectが公開するInterface集合からClient指定のDescriptorを一つ固定し、そのDescriptorに宣言されたOperationをObjectのHost内implementationへ適用する。

また、Protocol validation、Interface Descriptorの公開、Value validation、error mapping、resource limit等も担う。一方、backend固有のprojection resolutionやdomain operation implementationそのものは、Provider等のHost componentへ委譲できる。

Object implementationとOperation実装を接続する具体的なAPIは、各言語のSDK側で決める。これはHost内の実装を接続するためのAPIであり、新たなProtocol conceptとしては追加しない。

Working terminology

Host内部の投影処理を検討するため、次の語を使う。

Backend Entity — File、database row、issue、repository、remote entity等、projectionの入力になり得るHost固有の実体。一つのProjected Objectと一対一に対応するとは限らない。
Projection Resolution — 現在の主体とpathについて、公開するObject representationと、後続処理に必要なHost-private情報を得るrequest-timeの解決結果。
Projection Provider — Pathと主体からProjection Resolutionを生成し、indexable childrenの発見を支援するHost component。
Projected Object — その時点でClientへ返すProtocol Object。Backend Entityを持たないvirtual Object、一つのentityのprojection、複数entityのaggregateのいずれでもよく、Host内の常駐instanceを意味しない。

Operationの実装に使うRust struct、TypeScript object、backend handle、transaction context等はHost-privateである。これらに共通するHost abstractionは必須としない。また、ProtocolのTarget { path, validator }、canonical path、Objectのrefとして公開したり、それらへ流用したりしない。

運用モデル

`observe`

observe(path, depth)では、要求された範囲のObjectを現在の状態から投影する。Hostが概念的に行う処理は次のとおりである。

Requestの主体とpathをProjection Providerへ渡す。
Providerが現在のbackend stateから、そのpathで公開するProjected ObjectのProjection Resolutionを生成する。
非公開または存在しない場合はNotFoundとする。
公開する場合は、現在のObject metadata、Interface参照のordered set、optionalなrefとvalidatorを生成する。
Nodeのdepthがrequested depthより小さい場合、その主体へ公開するdirect indexable childrenをclean exhaustionまで列挙し、各childについて同じ処理を再帰的に行う。
Nodeがrequested depthに達した場合はchildrenを観測せず、responseのchildren fieldを省略する。
Requested depthまで完全なObjectObservationを返す。

Providerには、Worldspace全体をmaterializeせず、処理中のparentのdirect childrenを遅延して発見できることが必要になる。Host内部ではstream、iterator、cursor等でchildrenを生成してよい。ただし、一つのparentの観測を成功とするには、その主体へ公開するindexable childrenをすべて調べ終える必要がある。

Backend failure、cancellation、resource budget超過は、列挙が正常に完了したclean exhaustionとは区別する。Requested depthまで完全なresponseを構築できなければ、Host Runtimeは部分的なsuccess responseではなく、対応するfailureを返す。

列挙した各childについては、現在のObject projectionを構築し、そのcanonical pathを後のobserveやcall_operationで再解決できなければならない。再解決の対象は、その時点のProjected Objectである。以前観測したbackend entityやHost内部instanceの再現は要求しない。

したがって、Hostが以前のobserveで作ったObject instanceを保持する必要もない。内部cacheは利用してよいが、その有無でProtocol semanticsを変えてはならない。

`fetch_interface`

ProjectionがObjectへ割り当てた各Interface参照は、その主体から取得可能なDescriptorへ解決されなければならない。複数のObjectで同じ参照を共有でき、一つのObjectに複数のInterfaceを組み合わせることもできる。

Descriptorの変更可否は、Interface参照がvalidatorを返すかどうかで分かれる。Validatorを返す参照ではDescriptorを変更でき、同じ参照とvalidatorの組が一つのDescriptor observationを表す。Validatorを返さない参照では、その参照が有効な間、Descriptorはimmutableである。

Interface参照のscopeは2.2. Operation and Interfaceに従う。登録API、生成時期、deduplication、cacheの具体実装は別途決める。

`call_operation`

call_operationでは、現在のObjectを解決する処理と、そのObjectへの実行を同じexecution boundary内で行う。HostはProviderまたはbackend固有のboundaryに入り、概念的に次を行う。

現在の主体とtarget.pathからProjection Resolutionを生成し、同じbackend対象を保持するstable handleまたはtransaction contextを取得する。
そのpathのProjected Objectを現在も公開するか確認する。
指定されたObject validatorを現在のObject identityと状態へ照合する。
Clientが指定したInterface参照がObjectの現在のinterfacesに含まれることを確認する。
fetch_interfaceで観測したInterface validatorを現在状態へ照合する。
固定したInterface Descriptorで指定Operationが宣言されていることを確認する。
Argumentsを同じOperation Declarationに従って検証する。
固定したObject implementation、Interface Descriptor、Operation implementationを、step 1で固定した同じbackend対象へ適用する。
Resultを同じOperation Declarationで検証し、nestedしたすべてのEntryへ現在の主体のvisibility checkを適用してから、実行後Object validatorとともに返す。

Step 3から8までの間に、Object、Interface、Descriptor、Operation implementation、backend対象の対応が変わり得る実装では、この手順を満たせない。Host RuntimeとProviderがatomicityを実現できるよう、Projectionは必要なstable handle、transaction、conditional operation、lock等を使用できる必要がある。

解決には、過去のobserveで作ったHost内部Object instanceを前提としない。Clientから届くprotocol-level Targetはpathとoptionalなvalidatorであり、Hostはcall時の現在状態からObject implementationを解決する。現在のOperationがvalidatorの省略を許可する場合、callは過去に観測したObjectではなく、実行時にpathが指す現在のObjectへ無条件に実行する。

一方、validatorが指定されたcallでは、Clientが観測したObject identityと保護対象状態を実行対象へ照合する。Path、ref、以前のProjection Resolution、cacheされたHost内部instanceは、いずれも単独ではProtocol上の永続的なObject identityとして扱わない。

Filesystem projectionの評価例

Filesystemを/files以下へ投影する場合も、全file / directory分のObject instanceを作成する必要はない。Request時の解決と投影を、次のように行える。

observe("/files/a.txt", depth = 0)では、pathをfilesystem entryへ解決し、stat等からObject projectionを構築する。
observe("/files", depth = 1)では、directory listingから直接のindexable childrenをすべて列挙する。
Regular file、directory、symlink等に応じてInterface参照の集合を選択できる。
主体の権限に応じてObjectを非公開にしたり、read-only、writable等のcapability Interfaceを集合へ追加または除外できる。
File Operationでは、call時にpathを現在のfilesystem entryへ解決し、Rust struct、TypeScript object、file descriptor等を使ってOperationを実装できる。

この場合のObjectは、fileをWorldspace上で発見・操作するためのprotocol-level projectionである。Fileそのものを渡すわけでも、file内容を複製したrecordを渡すわけでもない。

要件

Lazyかつdata-drivenであること

Object集合を事前に列挙または常駐させなくてもよい。
Backend dataからrequest時にObjectを生成できる。
大規模または無限に近いlogical spaceを、要求範囲だけ投影できる。
Tree上でindexableでないObjectも、既知のpathをdepth = 0でobserveしたときに直接解決できる。
Operation resultのEntry等で新たに得たpathを、事前のObject登録なしに解決できる。
静的Objectも同じmodelで表現できる。

Protocol上有効なprojectionを生成すること

Rootと非rootに対するname規則を守る。
同じparentの公開childrenに重複するnameを生成しない。
Backend側の名前をそのままWIPのUnicode nameとして表現できない場合は、deterministicかつcanonicalで、同じparent内で衝突しないmappingを定義するか、そのentryを公開対象から除外する。
Mappingしたnameは、親全体の無制限列挙を前提にせず、depth = 0のobserveとOperation dispatchで同じchildへboundedに解決できなければならない。Encoding自体が可逆である必要はなく、boundedなbackend indexを利用してよい。
Name mappingはchild enumeration、observe、call_operationで一貫させる。
Objectのinterfacesを重複のないordered setとして生成し、各参照を取得可能で有効なInterface Descriptorへ解決する。
ProviderやOperation implementationの出力を信頼せず、Host RuntimeがProtocol boundaryで検証できる。
Invalidなbackend dataを、Protocol上有効に見える別のObjectへ暗黙に衝突させない。

Object representationとbackend dataを分離すること

Protocol Objectをbackend entity classやHost内のmutable instanceと同一視しない。
Object projectionはrequestごとに再構築できるvalueとして扱える。
Backend connection、database transaction、file descriptor、credential等をObject metadataへ混入させない。
Host内部のObject implementation stateはwire representationへ露出させない。

Interface DeclarationとObject publicationを分離すること

Interface DeclarationはObjectの個数やpathに依存しない。
多数の動的Objectが同じInterface参照を共有でき、一つのObjectも複数のInterfaceをordered setとして組み合わせられる。
Validatorを返すInterface参照は同じ参照でDescriptorを変更できるが、変更時にvalidatorを更新する。Validatorを返さない参照のDescriptorは、その参照が有効な間immutableとする。
Projectionは主体、policy、resource kind、安定した公開capabilityに基づいて、Objectのinterfacesへ含める参照と立項順を決定できる。
頻繁に変化する実行可否や通常のdomain stateを、Interface集合やOperation declarationへ同期しない。
Operationを隠す場合はcapability Interfaceを集合から除外するか、そのOperationを宣言しないDescriptorを使用し、公開済みOperationの実行だけを拒否する場合はPermissionDeniedを使用できる。
Objectのinterfacesに含まれる各Descriptorは、その主体から取得可能でなければならない。
Interface参照からDescriptorを解決することと、そのInterfaceを実装するHost codeを区別する。

`observe`と`call_operation`で一貫すること

同じ時点と主体について、異なるdepthの観測が矛盾したObject metadataを生成しない。
同じrefを持つObjectを複数pathへ投影する場合も、一つの共有された現在状態として扱い、path固有のname、description、Interface集合を同時に返さない。
同じrefと同じvalidator valueを持つObject projectionは、validatorが存在する場合、name、description、interfacesを含む全representationを一致させる。
同じrefでvalidatorが異なる場合は同一Objectの異なる観測状態であり、別Objectとして扱わない。
Validatorが存在しないObjectでは同validatorによるrepresentation equality checkを行えないため、Clientが最後に成功した観測を現在状態として扱えるようにする。
同じrefを持つObjectの公開representationが変化する場合は、validatorが存在するなら以前と同じvalidatorのまま異なるrepresentationを返さない。
深いobserveで得たpathをdepth = 0で再観測した場合に、backend stateが変化していなければ同じObjectとして解釈できる。
Operation call時には、その時点でpathが指す現在のProjected ObjectとInterface集合を再解決し、Clientが指定した参照のmembershipとvalidatorを確認する。
非公開Object、非公開Operation、公開済みだが実行拒否されたOperationをProtocolで定めたerrorへ一貫して対応付ける。

Backendが並行して変化する場合、複数request間で同じsnapshotを保証することまでは要求しない。観測したObject identityと状態を条件付き実行の対象へ対応付けるため、validatorを使う。Operationがvalidatorの省略を許可すれば、callは実行時の現在Objectへ無条件に実行する。Validatorを要求するOperationでは、省略されたcallをValidatorRequiredとして拒否し、実行しない。

Operation解決と実行対象のatomicity

Operation callでは、visibility、Object identityとvalidator、Interface membershipとvalidator、Interface Descriptor、Operation implementation、backend対象を、一つのlinearization pointで固定しなければならない。Object validatorなしの実行をOperationが許可する場合も、この固定は必要である。解決後にpathの指すProjected Objectが変わり、以前のDescriptorに基づくOperation implementationが現在の別Objectへ適用されることは許さない。

少なくとも次の処理を、一つのatomicなexecution boundaryとして扱える必要がある。

Pathが現在指すObject identityと保護対象状態の確認。
Object validatorの必須判定と比較。
指定Interfaceの現在のmembership確認。
Interface validatorの必須判定と比較。
Interface DescriptorとOperation implementationの固定。
Authorizationの確認。
同じbackend対象へのOperation実行。

Pathを一度解決してvalidatorを比較しても、その後に同じpathを別途開き直して実行すると、比較と実行の間に対象が差し替わる可能性がある。

そのためHost APIには、Providerがbackendに適した方法でatomicityを実現できる境界が必要になる。Backend transaction、lock、revision付きconditional update、file descriptor、identity再確認等を利用できるようにするが、すべてのbackendに共通する特定のlocking方式は要求しない。

Host内部Object stateのlifecycleを限定できること

Rust struct、TypeScript object、backend handle等をrequestまたはOperation execution scopeだけで構築できる。
Hostは全Object分のimplementation instanceを保持しなくてよい。
Providerは必要に応じてconnection poolやmetadata cache等を共有できる。
Request終了後の内部state保持、再利用、破棄はbackend entity、connection、transaction等の安全性を損なわない。
Clientが保持するrefやvalidatorからHost内部instanceを直接復元することを要求しない。

認可をrequest時に評価できること

Projectionは主体に基づいてObject visibilityと、Objectのinterfacesへ含める参照の集合を決定できる。
非公開ObjectとそのObjectだけを経由するsubtreeをobserve responseから省略し、存在や省略数を示すmarkerを生成しない。
Requested depthより浅いnodeでは、その主体へ公開されたindexable childrenを完全に返す。
Operation implementationまたはその前段で、call時のauthorizationを再評価できる。
以前のobserve時に許可されていたことだけを根拠にOperationを実行しない。
非公開Objectの存在や非公開Operationを内部error、log、timing等から不用意に漏らさない実装が可能である。
Operation resultへEntry pathを含める場合もObject visibilityを迂回せず、result生成時点でその主体に認識させてよいpathだけを返す。この規則はRecord、List、Union等へnestedしたすべてのEntry位置へ再帰的に適用する。
Entry argumentや既知pathの所持をauthorizationの証明として扱わず、参照先へ作用するOperationは現在の主体と状態に基づいて認可する。
Result取得後のstateまたは権限変更により、そのEntryへの後続observeがNotFoundになることは許容する。

Backend固有のidentityを強制しないこと

Providerは適切なbackend identityがある場合にrefへ利用できる。
Backend EntityとProtocol Objectを常に一対一対応させず、例えば同じfilesystem identityが異なる名前で同時に現れ、Object representationの整合性規則を満たせない場合は、同じrefを機械的に再利用しない。
Backendに安定したUIDがなくてもObjectを投影できる。
Host内部のexecution identityとClient-facingなrefを同一形式にする必要はない。
refをHost内部instanceのhandleやdereference keyとして使用することを要求しない。
refを持たないObjectでもvalidatorを用いた安全なOperationを実装できる。
Validatorは状態だけでなく現在のObject identityにも結び付け、pathが別Objectを指す場合は内容が同じでも一致させない。

Resource limitとcancellationを適用できること

Child enumeration、backend lookup、descriptor生成、Value変換へboundedなresource limitを適用できる。
observeのdepthをProvider側の無制限な再帰列挙へ変換せず、request全体へboundedなresource budgetを適用する。
Client disconnect、timeout、Host shutdown等に応じてbackend処理へcancellationを伝播できる。
call_operationをdispatchする前にresource limitへ達した場合はResourceLimitExceededとして拒否し、Operationを実行しない。
Dispatch後のcancellation、timeout、implementation failure、result encoding failureについて、Operationが未実行またはrollback済みであると保証できる場合だけInternalまたはResourceLimitExceededを返す。保証できない場合はOperationOutcomeUnknownを返す。
Side effectを持つOperationでは、cancellationやtimeoutを未実行またはrollback済みの証明として扱わず、Host RuntimeもClientも実行結果が不明なcallを自動retryしない。
Partial backend failureをProtocol上の成功したObject observationへ黙って変換しない。

RustとTypeScriptで同じsemanticsを表現できること

RustとTypeScriptでAPI syntaxが異なっても、次の処理や制約は両方で実現できなければならない。

Asyncなpath resolutionとchild enumeration。
Data-drivenなObject projection。
Interface Declarationの共有と、Objectへの0個以上のInterfaceのcomposition。
Type-safeまたはruntime-validatedなOperation dispatch。
Host-privateなObject implementation stateをrequest-timeに構築および利用できること。
Object validator、Interface membershipとvalidator、Descriptor、Operation implementation、backend対象の一貫したlinearization point。
Request context、主体、cancellation、resource limitの伝播。
Protocol errorとbackend / implementation errorの分離。

Rustのtrait、generic、associated type、type erasureや、TypeScriptのobject definition、generic inference、runtime schema libraryの選択は、これらの要件を満たすAPIを設計する段階で決める。

Host内部cache

Host内部のcacheは性能最適化であり、Protocol contractではない。Path resolution、backend metadata、Object projection、Interface Descriptor、Host内部Object state等をcacheしてよいが、次の条件を守る必要がある。

Cacheがなくても正しく動作しなければならない。
Visibilityとauthorizationを異なる主体間で誤って共有してはならない。
Stale cacheによってvalidator比較を迂回してはならない。
Descriptor cacheは同じInterface参照とvalidatorの組に異なるDescriptorを対応付けず、validatorを返さない参照をimmutableとして扱う。
Resource handleをcacheする場合は、そのlifecycleとidentityの再確認をbackendに適した方法で行う。

Composition

一つのHostで、Filesystem、database、remote API等の複数Providerを一つのWorldspaceへ合成できることが望ましい。

合成する場合も、同じ主体へ公開するWorldspace全体でrefとInterface参照のProtocol semanticsを保たなければならない。Provider-local identityやInterface keyをそのまま公開すると衝突し得るため、Hostはnamespace、変換、中央発行等によって次を保証する。

異なるObjectへ同じ有効なrefを割り当てない。
同じ有効なInterface参照とvalidatorの組を異なるDescriptorへ対応付けない。
Validator比較がProvider routingの変更によって別Objectへ適用されない。

Interface参照には、2.2. Operation and Interfaceの構造化参照を使う。Objectの祖先制約と、合成後のscope・path・typed entryの変換は、ProtocolのWorldspace compositionに従う。Objectのrefを具体的にどう発行するかは、引き続き未決定である。

ScopeはそのpathのObjectに紐づき、self-scopeも許可する。RuntimeはDescriptorとscope Objectのoptionalなrefを一つのInterface observationとして公開する。Callで指定されたscope_refは、routing・implementationの固定と一貫して確認する。refのないscopeも許可し、そのidentityの追跡は要求しない。

Host内部の合成方法については、mount API、path routing、Provider間のparent / child関係、同名entry conflict、cross-provider Operation、transaction boundaryが未決定である。ProtocolではHost内部のcomposition方式を公開しないため、これらをHost APIでどこまで標準化するかは別途検討する。

非目標

動的projectionの要件には、次を含めない。

Worldspace全体の事前materialization。
Objectごとの常駐class instanceまたはactor。
Backend entityとProtocol Objectの一対一対応。
Host内部Object state、database key、file descriptor等のwire公開。
Client cacheとHost stateの同期。
Provider間にまたがる分散transaction。
すべてのObjectに対するrefの発行。
特定のdependency injection framework、schema library、async runtimeの採用。

API設計前に評価するシナリオ

具体API案は、少なくとも次のシナリオで評価する。不自然な大量登録や、永続Object instanceの保持を要求しないことを確認する必要がある。

数百万entryを持つFilesystemを、directory listingに応じて遅延投影する。
Database tableのrowをObjectとして投影し、row keyからcall時に再解決する。
検索Operationが、Treeではindexableでない結果ObjectのEntry pathを返す。
同じbackend dataを元に、主体ごとに異なるObject visibilityまたはInterface集合を公開する。
観測後にpathの指すProjected Objectが変化し、validator付きOperationを拒否する。
公開済みOperationをcall時のauthorizationでPermissionDeniedにする。
固定pathの静的service endpointを、動的modelの特殊ケースとして公開する。
複数Providerを一つのWorldspaceへ合成し、Provider-localなidentityの衝突を防ぐ。
Backend entityを持たないvirtual Objectと、複数entityを集約するObjectへOperation implementationを適用する。
深いobserveがresource budgetを超える場合、部分的なresponseを返さずResourceLimitExceededにする。
Operation resultのnestedなEntryから、現在の主体へ非公開のObject pathが漏れないようにする。

未決定事項

Projection ProviderをHostへ登録・合成する単位。
Path routingおよびmountに相当する概念を標準Host APIへ含めるか。
Path resolutionとchild discoveryの具体的な戻り値。
Projected Objectがzero / one / multiple backend entityから導出される場合のHost内部Object implementation表現。
Child discoveryがObject projectionを返すか、遅延解決用の内部keyを返すか。
Clean exhaustion、failure、cancellationを区別し、requested depthまで完全な観測だけをsuccessとして返せる内部contract。
Rust structやTypeScript objectを、Interface DeclarationおよびOperation implementationへ接続する言語別API。
DynamicなProjected Object implementationをProviderから返すときのgeneric、type erasure、runtime representation。
Interface DeclarationとOperation implementationを同じAPIにするか分離するか。
Validator比較とOperation実行を囲むtransaction / callback / guardの抽象化。
Backendがatomic conditional executionを提供できない場合に、そのOperationをどう制限するか。
Subject-specificなInterface参照の選択、Descriptor生成、参照発行、cache方法。
Descriptorを事前登録するか必要時に生成するか、および構造的に等しいDescriptorをinternするか。
Operation result内のnestedなEntry visibilityを、Operation implementation、Projection、Host Runtimeのどこで検証するか。
Backend nameをWIP nameへmappingする場合のencoding、index、collision処理。
複数Provider間でref、Interface参照、validator identityをnamespace化する方法。
Projection、Operation implementation、Host Runtimeが返すerrorとProtocolErrorの対応付け。
Enumerationのstreaming、pagination、backpressureをHost内部APIでどう表すか。
Provider composition時のconflict、ownership、lifecycle、shutdown順序。
Observability、tracing、auditで非公開Objectやsecretを漏らさないための標準hook。

これらの決定に先立ち、Rust / TypeScript双方で複数のAPI sketchを作る。各案をここに挙げた評価シナリオと要件に照らして比較し、具体的なAPIを検討する。

30 KiB Raw Permalink Blame History