《A Technique for Drawing Directed Graphs》 http://www.graphviz.org/Documentation/TSE93.pdf
this is useful for us. We can use this way to describe the graph after plug-in orchestration. I will create a GitHub PR for more detail(including picture), we need more detail to confirm the first design. On Mon, Jun 22, 2020 at 9:40 AM Linsir Wu <[email protected]> wrote: > That's great. > > Ming Wen <[email protected]> 于2020年6月21日周日 上午9:47写道： > > > > No, dashboard can help users to understand how to use plugins. > > > > agile6v <[email protected]> 于 2020年6月20日周六 下午7:31写道： > > > > > Hi > > > > > > That's great. > > > > > > Does this mean users need to have a clear understanding of how each > plugin > > > works? > > > > > > Thanks. > > > > > > On 2020/06/20 02:12:02, YuanSheng Wang <[email protected]> wrote: > > > > This new way is very different from the old one. > > > > > > > > I love this new way. > > > > > > > > According to this idea, plug-ins will be more like micro-plug-ins, > and we > > > > can execute these micro-plug-ins one by one by way of arrangement. > > > > > > > > And will make these micro plug-ins become more independent and > simple. > > > > > > > > > > > > On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <[email protected]> wrote: > > > > > > > > > Hello, > > > > > I want to discuss a new idea about plugins, and let me start by > > > explaining > > > > > the existing plugin mechanism, plugins works according to the > following > > > > > rules: > > > > > - plugins are executed after the administrator binds them to a > route, > > > > > service, unless they are modified again by the admin API > > > > > - plugins are executed in order of priority which hard code > > > > > - plugins are independent of each other, the results of a plu-in > will > > > not > > > > > affect another plugin > > > > > > > > > > So, some scenarios are not handled very gracefully by Apache > APISIX, > > > such > > > > > as: > > > > > - limit-count for some IPs, and others are unrestricted > > > > > - throw the failed authentication logs to kafka topic A, and > others to > > > > > kafka topic B > > > > > - request which block by limit-req need to go through the fault > > > injection > > > > > plugin > > > > > > > > > > For these scenarios, we can now only handle them by creating > multiple > > > > > routes, or creating new plugins. > > > > > > > > > > So I think it's time to take `brain` to APISIX to orchestrate > plugins. > > > We > > > > > can add an additional plugin orchestrator without any > modifications to > > > the > > > > > existing plugins, then we can use decision tree to control plugins. > > > > > > > > > > What do you think? > > > > > > > > > > Thanks, > > > > > Ming Wen, Apache APISIX & Apache SkyWalking > > > > > Twitter: _WenMing > > > > > > > > > > > > > > > > > -- > > > > > > > > *MembPhis* > > > > My GitHub: https://github.com/membphis > > > > Apache APISIX: https://github.com/apache/incubator-apisix > > > > > > > > -- *MembPhis* My GitHub: https://github.com/membphis Apache APISIX: https://github.com/apache/incubator-apisix
