Replies: 1 comment 1 reply
-
I understand the desire for extensibility and community-driven plugins. However, it's essential to acknowledge that building a robust plugin framework is a highly complex task, often more challenging than creating a plugin or simply implementing a standalone feature itself. While we appreciate the enthusiasm, we must prioritize our efforts wisely. A plugin framework requires a deep understanding of our architecture, a well-designed API, and rigorous testing. It's crucial to recognize that this might be the most difficult item on our current wishlist of features. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The hook of the first sentence of this project starts with the word "extensible". How exactly is it extensible, is there a way to create plugins for this, or framework for new components. What is the right way to go about extending functionality, is there an entry point that we should tie or code into, or an api across the modules for easily importing new features?
It's clear there's alot of interest in this project, many problems could be initially solved by the community if we had a way to be able to create modular solutions? Someone could potentially team infrastructure which extends plugins to whole user classes, or new RAG capabilities. If you "leave the implementation of HTTPS termination to the users for their production deployments" then why not just let the community build it once as a plugin.
If there is a clear way to do this already please fill me in. If not, then a plugin framework that allows inserting plugins at various stages might make sense, that way you can easily configure or orchestrate what's on and off. Entry points for plugins I can see include:
Beta Was this translation helpful? Give feedback.
All reactions