Namespaced entries with index pages #45

New Issue

Jef Roosens · 2023-12-10T13:13:46+01:00

Jef Roosens commented

2023-12-10 13:13:46 +01:00

An interesting concept I think would be introducing grouped entries that have a common index page. Here, the user would first add the namespace as a new entry type (perhaps with a -N flag in landerctl), e.g. /n/test. To add entries to this namespace, one would then simply prepend test_ to the entries' keys, e.g. test_1, test_something etc. /test would then return a list of all entries that have this same prefix. With this design, we could start hosting groups of files easily, with an index page so users can see all the related files. This page would then be generated dynamically so that it always contains the full list of entries.

To support this efficiently, the LSM store would need to support returning a list of entries with a given prefix. I don't think this would be too hard to implement, as this would come down to traversing the tree down to where the prefix ends, and then recursively finding all entries in that subtree.

The index endpoint should probably also listen to the Accept header, e.g. for browsers we would return a simple HTML page, while the CLI tool would retrieve a simple list of links.

An interesting concept I think would be introducing grouped entries that have a common index page. Here, the user would first add the namespace as a new entry type (perhaps with a `-N` flag in landerctl), e.g. `/n/test`. To add entries to this namespace, one would then simply prepend `test_` to the entries' keys, e.g. `test_1`, `test_something` etc. `/test` would then return a list of all entries that have this same prefix. With this design, we could start hosting groups of files easily, with an index page so users can see all the related files. This page would then be generated dynamically so that it always contains the full list of entries. To support this efficiently, the LSM store would need to support returning a list of entries with a given prefix. I don't think this would be too hard to implement, as this would come down to traversing the tree down to where the prefix ends, and then recursively finding all entries in that subtree. The index endpoint should probably also listen to the Accept header, e.g. for browsers we would return a simple HTML page, while the CLI tool would retrieve a simple list of links.

Jef Roosens added the

idea

label 2023-12-10 13:13:46 +01:00

Jef Roosens commented

2023-12-10 14:19:21 +01:00

Poster

We could add it so that POST-ing to a namespace URL automatically adds a new entry to the namespace with a randomized key. This way, the CLI tool could first create the namespace and then populate it with a list of given files by POST-ing them to the namespace URL one by one.

We could add it so that `POST`-ing to a namespace URL automatically adds a new entry to the namespace with a randomized key. This way, the CLI tool could first create the namespace and then populate it with a list of given files by `POST`-ing them to the namespace URL one by one.

Jef Roosens commented

2023-12-10 19:59:57 +01:00

Poster

Instead of making the namespace routes POST-able, it might be better to add a namespace or n query param to the existing routes. For example, doing POST /s/?n=test would create a random key prefixed with test_.

Instead of making the namespace routes `POST`-able, it might be better to add a `namespace` or `n` query param to the existing routes. For example, doing `POST /s/?n=test` would create a random key prefixed with `test_`.

Jef Roosens added

enhancement

and removed

idea

labels 2024-02-19 21:46:17 +01:00

Jef Roosens added

feature

and removed

enhancement

labels 2024-02-19 22:30:08 +01:00

Sign in to join this conversation.