From 0d3d6346724a5c463168017a2b64cfc78e59a37c Mon Sep 17 00:00:00 2001 From: Jeremy Wall Date: Tue, 15 Apr 2025 22:10:43 -0400 Subject: [PATCH] docs: Update our DESIGN.md with new inforatiom --- DESIGN.md | 86 +++++++++++-------------------------------------------- 1 file changed, 17 insertions(+), 69 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index 981549f..2d77747 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -2,22 +2,20 @@ ## Synchronization -We assume that our resources map easily to REST concepts. +We support several operations for Bootstrapping -- Resources map to a path. -- Groups of resources are represented in the path structure. -- `HEAD` to get the header to check whether we need to sync. -- `POST` is create -- `PUT` is mutate -- `GET` retrieves the resource -- `DELETE` removes the resources +* Fetch Bootstrap +* Fetch Reference +* Fetch Object -## Resource Query Datamodel +## Resource Datamodel We assume all resources are content-addressable and form a merkle tree. We maintain an index of path to content-addressable items. -Resource reference paths are rooted at `/api/v1/ref/`. +Resource reference paths are rooted at a `/ref/` prefix for their path +namespace. They contain a payload with the `objectID`, `content_address` if +there is one, and a list of any dependent resources. ```json { @@ -39,82 +37,32 @@ Resource reference paths are rooted at `/api/v1/ref/`. } ``` -Resource references contain a payload with the objectID and a list of any -dependent resources. They support the following operations - -* `GET` -* `POST` -* `PUT` -* `DELETE` -* `HEAD` - -`HEAD` requests return only the objectId in the payload. Primarily used to detect -if a reference needs to be updated on the client or not. - -Resource Requests can be expanded to their object reference payloads at any -configurable depth with the query parameters `?depth=` or to the full -tree depth with `?full=true`. This will add recursive dependent sections to the -content key. - -```json -{ - "objectId": , - "path": "/path/name0", - "dependents": [ - { - "objectId": , - "path": "path/name1", - "content": { - "objectId": , - "dependents": [ - { - "path": "path/name1", - "content_address": , - "objectId": , content: - }, - { - "path": "path/name2", - "content_address": , - "objectId": , content: - } - ], - } - } - ] -} -``` - ### Reserved References -* `/api/v1/ref/all/` The root of the resouce tree. List all sub +* `/ref/all/` The root of the resouce tree. List all sub resources that the user has access too. -* `/api/v1/ref/user/` The user information. +* `/ref/user/` The user information. ### Content-Addressable Query API The content addressable store is considered immutable. You do not delete from it. We may garbage collect at some point as a storage optimization. -Content addressable paths are rooted at `/api/v1/object/`. +Content addressable paths are rooted at `/object/`. -Their payloads are whatever the contents serialize to in json and support the following -operations. - -* `GET` -* `POST` +Their payloads are whatever the contents serialize to in json ## Syncrhonization ### Bootstrapping -* Load `/api/v1/ref/all/` and then follow the sub resources to - load the entire dataset locally making sure to keep the content-addresses - around for comparison. +* Load `/ref/all/` +* Follow the sub resources recusively to load the entire dataset locally making + sure to keep the content-addresses around for comparison. # Benchmarking ## Bootstrapping benchmark tests -* Server side loading -* Client side loading -* WebSocket? +* Rest API +* WebSockets