Replies: 1 comment 2 replies
-
@yairgott Just to make sure I understand what you're saying, you're not talking about the API between the module and Valkey, you're talking about the API between the end user and the module? Having working groups per module seems like a good idea. I would like to see the TSC oversee decisions, but we already have the primitives in place in the governance draft to allow them to delegate decisions. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Modules provide a great way to enhance ValKey functionality and to grow our community. One challenge with a community-driven approach for modules is the risk of contributors evolving their APIs in different directions. This divergence may lead to difficulties in usability, sustaining clients being up to date, and more.
To benefit ValKey and our users, the TSC committee may establish standardization around APIs and general clear module qualification criterias. Ideally, this standardization would be driven not directly by the TSC, but by a subcommittee with domain expertise and credibility in a particular domain. Meeting the qualification means that the module is endorsed by ValKey. To clarify, my proposal is saying that it is perfectly fine to have more than a single qualified module per domain, like json, vector search, etc. At the end of the day, we let the user decide and let the modules organically evolve over time.
Happy to get your thoughts.
Beta Was this translation helpful? Give feedback.
All reactions