> if we want have the marketplace, the version dependency is necessary. No thanks. The marketplace is not even in the 2022 roadmap.
> if the plugin is independent. the user can write their own plugins, and install it by apisix-dashboard or other method for dynamic installing. Currently, we already support users to write their own plugin. Fei Liang <bsch1...@gmail.com> 于2022年3月15日周二 15:37写道： > > > In fact, the split will make the situation more complex. > > Now we require the `package.json` stuff and need to handle complex > > dependency cases (like the apisix-base I mentioned in that issue). > > These problems are not existent if we don't split the plugin. > > We have to develop a custom new package manager to solve these new > > problems. Why bother to create more problems? > > split the plugin, don't mean split the depend repo, if we wan't marketplace. > in fact, the APISIX is also support the method. /apisix/plugins/ext-plugin. > > > > Also, it is very tough to sync the schema between Dashboard & Ingress > > control & other components, if each plugin has its own schema version. > > if the plugin is independent. the user can write their own plugins, and > install it by apisix-dashboard or other method for dynamic installing. > > > BTW, even for developers, the split is also disaster when you try to > > upgrade APISIX. The more we split, the more chain reaction we will > > meet. > > Dependency hell warning! > > split the plugin, don't mean split the depend repo, if we wan't have > marketplace. > > if we want have the marketplace, the version dependency is necessary. > in fact. Ecosystems cannot depend on APISIX. and the thirdpart. > Most software that supports plugin, has the marketplace, eg vscode, emacs, > vim > or manual installation mode. > All similar software faces this problem. > > > Compared with similar open source projects: > > 1. Envoy doesn't and can't split filters out of the core > > 2. Kong used to split some of the plugins out. But now they are merged > > them back. > > i only proposal refactoring the plugins code organization. > split the independent repo or independent directory could discuss. it only > just depends on if we have marketplace. > > > We should not lead Apache APISIX to the wrong path, right? > > Only through discussion can we know whether the direction is correct or not. > Instead of someone saying right is right, saying wrong is wrong > > Zexuan Luo <spacewan...@apache.org> 于2022年3月15日周二 12:46写道： > > > In fact, the split will make the situation more complex. > > Now we require the `package.json` stuff and need to handle complex > > dependency cases (like the apisix-base I mentioned in that issue). > > These problems are not existent if we don't split the plugin. > > We have to develop a custom new package manager to solve these new > > problems. Why bother to create more problems? > > > > Also, it is very tough to sync the schema between Dashboard & Ingress > > control & other components, if each plugin has its own schema version. > > > > BTW, even for developers, the split is also disaster when you try to > > upgrade APISIX. The more we split, the more chain reaction we will > > meet. > > Dependency hell warning! > > > > Compared with similar open source projects: > > 1. Envoy doesn't and can't split filters out of the core > > 2. Kong used to split some of the plugins out. But now they are merged > > them back. > > > > We should not lead Apache APISIX to the wrong path, right? > > > > Chao Zhang <zchao1...@gmail.com> 于2022年3月15日周二 11:48写道： > > > > > > Hi Fei, > > > > > > I have some doubts about the proposal: > > > > > > 1. Term Compile is too generic, could you give us some examples about > > this > > > process; > > > 2. How could can help developers to integrate APISIX and this plugin, so > > > that developers can test the plugin successfully; > > > 3. I didn’t get the key point of package.json, the entry point code > > > actually can be specified (such as from the init.lua). > > > > > > Chao Zhang > > > https://github.com/tokers > > > > > > On March 15, 2022 at 10:54:47, Fei Liang (bsch1...@gmail.com) wrote: > > > > > > stable, the addition of the plugin will be dynamic and frequent. > >
