Problem
Currently we render the file browser from pretty paths on Ref blobs. Then we employ some clever tricks to materialize this hierarchy as embed card links from parents to children.
In the new resource architecture we make it more explicit, and pretty paths as we know them right now are gone — resource will have canonical stable opaque identifiers.
See Unified Hypermedia Resource Architecture for prior context.
Solution
File explorer should be rendered based on embeds in the document, not from paths in Ref blobs.
Ref blobs still contribute pretty paths to the URL resolver, as aliases to opaque resource IDs.
We should prefer using opaque resource IDs from now on, to make sure our links are more resilient to moves and renames.
Ideally we won't render children of collections, to avoid overloading the file browser, and because there's no meaningful order we can have there as it's based on the query.
Rabbit Holes
What about existing query blocks? They currently select resources by pretty path prefix most of the time.
Embed blocks could have non-random block IDs to contribute themselves to the pretty paths. hm://<space>/:r/<resource-id>/<name> URL form can be used to zoom or traverse. How to distinguish zoom from traverse though?
Will we traverse only if block is embed, or any block with a URL
Invite a writer to a subtree of resources considering the fact that hierarchies are not authoritative and just links. TODO design sketch.
Home (rid="")
/cars (rid="asdf")
/toyota (rid="xyz") hm://<somespace>/:r/xyz
hm://<somespace>/cars/toyota
Example:
Doc ID: hm://<space>/:r/readme/b1
b1: just a block
my-doc (embed): Unified Hypermedia Resource Architecture
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime