redict/redict-doc
7
3
Fork
You've already forked redict-doc
3

Move documentation to redis/redis.io #18

Merged
ddevault merged 2 commits from :main into main 2024年04月02日 10:59:23 +02:00

This is the companion PR to redict/redict.io#18

It adjusts the links in the commands.

Delete all the documentation that I moved to redict/redict.io. Removed things that are Redis specific (like "Redis Insight") or only in old versions (like Gopher protocol support).

This leaves only a few bits of documentation that did not fit the "Usage" category in my opinion:

docs
├── manual
│ ├── client-side-caching.md
│ └── keyspace-notifications.md
└── reference
 ├── arm.md
 ├── clients.md
 ├── cluster-spec.md
 ├── internals
 │ ├── _index.md
 │ ├── internals-rediseventlib.md
 │ ├── internals-sds.md
 │ ├── internals-vm.md
 │ └── rdd.md
 ├── key-specs.md
 ├── protocol-spec.md
 └── sentinel-clients.md

Most of these are either specs or for implementors. Not sure what we should do with these.

This is the companion PR to https://codeberg.org/redict/redict.io/pulls/18 It adjusts the links in the commands. Delete all the documentation that I moved to `redict/redict.io`. Removed things that are Redis specific (like "Redis Insight") or only in old versions (like Gopher protocol support). This leaves only a few bits of documentation that did not fit the "Usage" category in my opinion: ``` docs ├── manual │ ├── client-side-caching.md │ └── keyspace-notifications.md └── reference ├── arm.md ├── clients.md ├── cluster-spec.md ├── internals │ ├── _index.md │ ├── internals-rediseventlib.md │ ├── internals-sds.md │ ├── internals-vm.md │ └── rdd.md ├── key-specs.md ├── protocol-spec.md └── sentinel-clients.md ``` Most of these are either specs or for implementors. Not sure what we should do with these.
Author
Owner
Copy link

This does not yet extract the patterns to their own pages as outlined in #15. I will do that as a follow up, but not today 😄

This does not yet extract the patterns to their own pages as outlined in #15. I will do that as a follow up, but not today 😄

What to do with these? Suggestions inline

docs
├── manual
│ ├── client-side-caching.md - usage/clients
│ └── keyspace-notifications.md - usage/clients
└── reference
 ├── arm.md - drop
 ├── clients.md - move to redict/redict codeberg wiki
 ├── cluster-spec.md - move to codeberg wiki
 ├── internals - move to codeberg wiki
 │ ├── _index.md
 │ ├── internals-rediseventlib.md
 │ ├── internals-sds.md
 │ ├── internals-vm.md
 │ └── rdd.md
 ├── key-specs.md - usage/clients
 ├── protocol-spec.md - drop, redundant with RESP3 spec on github (we can discuss adopting the spec later)
 └── sentinel-clients - usage/clients

Summary:

  • Establish usage/clients for docs whose audience is client authors
  • Move internal documentation to codeberg wiki
  • drop everything else
What to do with these? Suggestions inline ``` docs ├── manual │ ├── client-side-caching.md - usage/clients │ └── keyspace-notifications.md - usage/clients └── reference ├── arm.md - drop ├── clients.md - move to redict/redict codeberg wiki ├── cluster-spec.md - move to codeberg wiki ├── internals - move to codeberg wiki │ ├── _index.md │ ├── internals-rediseventlib.md │ ├── internals-sds.md │ ├── internals-vm.md │ └── rdd.md ├── key-specs.md - usage/clients ├── protocol-spec.md - drop, redundant with RESP3 spec on github (we can discuss adopting the spec later) └── sentinel-clients - usage/clients ``` Summary: * Establish usage/clients for docs whose audience is client authors * Move internal documentation to codeberg wiki * drop everything else
Author
Owner
Copy link
  • usage/clients for client authors sounds like a good idea 👍
  • Let's try out moving these topics to the wiki 👍

Ran a linkchecker yesterday #17, the remaining ones were:

  • /topics/protocol ⇒ We will link to the RESP3 spec on GitHub instead, right?
  • /topics/cluster-spec ⇒ Link the wiki
  • /topics/key-specs ⇒ Link usage/clients/key-specs
  • /topics/sentinel-clients ⇒ Link usage/clients/sentinel-clients
  • /topics/notifications ⇒ Link usage/clients/keyspace-notifications
* `usage/clients` for client authors sounds like a good idea 👍 * Let's try out moving these topics to the wiki 👍 Ran a linkchecker yesterday #17, the remaining ones were: * `/topics/protocol` ⇒ We will link to the RESP3 spec on GitHub instead, right? * `/topics/cluster-spec` ⇒ Link the wiki * `/topics/key-specs` ⇒ Link usage/clients/key-specs * `/topics/sentinel-clients` ⇒ Link usage/clients/sentinel-clients * `/topics/notifications` ⇒ Link usage/clients/keyspace-notifications

We will link to the RESP3 spec on GitHub instead, right?

For now, yes.

>We will link to the RESP3 spec on GitHub instead, right? For now, yes.
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
redict/redict-doc!18
Reference in a new issue
redict/redict-doc
No description provided.
Delete branch ":main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?