You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apisix.apache.org by Damon Chen <ne...@gmail.com> on 2020/05/12 02:20:05 UTC
[DISCUSS] Better management of plugins by users and third-party developers
Hi, all:
If the plugin has a security problem or a bug which must be fixed at that
time,
the user who use the APISIX also must upgrade to the newest version. The
problem is that
if you upgrade the plugin, you should also upgrade the APISIX core. If the
new version of the APISIX core is not compatible of the old
APISIX core. How would you do it?
When you are in a company and want to write a plugin for your privacy
service.
You should more careful to maintain you plugin about how to install,
upgrade, etc.
Everyone who writes the plugin for privacy service also will do what you
have done.
There are many duplicate works.
When the user of the APISIX need some features, which may be developed by
some other developer,
how can we found in the web? cloning the APISIX repository and then search
the plugin
are not very effective and intuitive.
What we should to do is separating the APISIX core implement and the plugin
implement, introducing
a plugin center registry, adding a new cli tool for managing plugin for
installing, upgrading, removing,
searching, etc, and must be in accordance with the sematic version rule
both of the APISIX core and
the plugin. If we do this, we could solved the above problems.
*Detail*
The following image show how to separate the APISIX core and the plugin.
[image: image.png]
1. All the plugins will be placed the APISIX core subdirectory named
"plugins", eg: If we install the APISIX in the path /opt/apisix, then
all the plugins will be found in /opt/apisix/plugins
2. Every plugin has a unique directory name.
3. The plugin directory name should be in the form of
{company|person}.{name}. {company|person} will be replaced with the
company name or person developer name, *and the **{name}** is the
current plugin name.* eg, current version of the APISIX have a plugin
named basic-auth，which will be changed to apisix.basic-auth if applying
the above rule.
4. Every plugin have an entry file for APISIX core searching, which named
index.lua.The file index.lua will export _M table ,which is the same as
before.
5. Extends the _M table description of the plugin.
*The CLI*
The system will be introduced a new command named a6. The following shows
all subcommands and describes functions:
- a6 install {company|person}.{name}: which will download
{company|person}.{name} from the center registry and install the
{company|person}.{name} to the plugins directory.
- a6 search name will show all plugin's names and descriptions that is
matched name
- a6 list will list all installed plugins in the local system.
- a6 init [{company|person}.{name}] will create a plugin directory with
some templates file.
- a6 push will push the current plugin directory to the remote center
registry with an authenticated account.
*The Center Registry*
The center registry will have a public domain, so the a6 command will
download the plugin from the domain by default.
The center registry will have a search page, which may be shown as below:
[image: image.png]
If click the box, then show the detail page as below:
[image: image.png]
--
DamonChen
Re: [DISCUSS] Better management of plugins by users and third-party developers
Posted by Damon Chen <ne...@gmail.com>.
I'm so sorry for that!
new issue created at https://github.com/apache/incubator-apisix/issues/1593
Ming Wen <we...@apache.org> 于2020年5月14日周四 下午5:37写道：
> Hi,Damon,
> The mailing list does not support images.
> Can you put the image in the github issue? thanks
>
> Thanks,
> Ming Wen, Apache APISIX & Apache SkyWalking
> Twitter: _WenMing
>
>
> Damon Chen <ne...@gmail.com> 于2020年5月12日周二 上午10:20写道：
>
> > Hi, all:
> >
> > If the plugin has a security problem or a bug which must be fixed at that
> > time,
> >
> > the user who use the APISIX also must upgrade to the newest version. The
> > problem is that
> >
> > if you upgrade the plugin, you should also upgrade the APISIX core. If
> the
> >
> > new version of the APISIX core is not compatible of the old
> >
> > APISIX core. How would you do it?
> >
> >
> >
> > When you are in a company and want to write a plugin for your privacy
> > service.
> >
> > You should more careful to maintain you plugin about how to install,
> > upgrade, etc.
> >
> > Everyone who writes the plugin for privacy service also will do what you
> > have done.
> >
> > There are many duplicate works.
> >
> >
> >
> > When the user of the APISIX need some features, which may be developed by
> > some other developer,
> >
> > how can we found in the web? cloning the APISIX repository and then
> search
> > the plugin
> >
> > are not very effective and intuitive.
> >
> >
> >
> > What we should to do is separating the APISIX core implement and the
> > plugin implement, introducing
> >
> > a plugin center registry, adding a new cli tool for managing plugin for
> > installing, upgrading, removing,
> >
> > searching, etc, and must be in accordance with the sematic version rule
> > both of the APISIX core and
> >
> > the plugin. If we do this, we could solved the above problems.
> >
> >
> > *Detail*
> >
> > The following image show how to separate the APISIX core and the plugin.
> >
> >
> > [image: image.png]
> >
> >
> >
> > 1. All the plugins will be placed the APISIX core subdirectory named
> > "plugins", eg: If we install the APISIX in the path /opt/apisix, then
> > all the plugins will be found in /opt/apisix/plugins
> > 2. Every plugin has a unique directory name.
> > 3. The plugin directory name should be in the form of
> > {company|person}.{name}. {company|person} will be replaced with the
> > company name or person developer name, *and the **{name}** is the
> > current plugin name.* eg, current version of the APISIX have a plugin
> > named basic-auth，which will be changed to apisix.basic-auth if
> > applying the above rule.
> > 4. Every plugin have an entry file for APISIX core searching, which
> > named index.lua.The file index.lua will export _M table ,which is the
> > same as before.
> > 5. Extends the _M table description of the plugin.
> >
> >
> > *The CLI*
> >
> > The system will be introduced a new command named a6. The following shows
> > all subcommands and describes functions:
> >
> > - a6 install {company|person}.{name}: which will download
> > {company|person}.{name} from the center registry and install the
> > {company|person}.{name} to the plugins directory.
> > - a6 search name will show all plugin's names and descriptions that is
> > matched name
> > - a6 list will list all installed plugins in the local system.
> > - a6 init [{company|person}.{name}] will create a plugin directory
> > with some templates file.
> > - a6 push will push the current plugin directory to the remote center
> > registry with an authenticated account.
> >
> >
> > *The Center Registry*
> >
> > The center registry will have a public domain, so the a6 command will
> > download the plugin from the domain by default.
> >
> > The center registry will have a search page, which may be shown as below:
> >
> > [image: image.png]
> >
> >
> >
> > If click the box, then show the detail page as below:
> >
> > [image: image.png]
> >
> >
> >
> >
> > --
> > DamonChen
> >
> >
> >
>
--
DamonChen
Re: [DISCUSS] Better management of plugins by users and third-party developers
Posted by Ming Wen <we...@apache.org>.
Hi,Damon,
The mailing list does not support images.
Can you put the image in the github issue? thanks
Thanks,
Ming Wen, Apache APISIX & Apache SkyWalking
Twitter: _WenMing
Damon Chen <ne...@gmail.com> 于2020年5月12日周二 上午10:20写道：
> Hi, all:
>
> If the plugin has a security problem or a bug which must be fixed at that
> time,
>
> the user who use the APISIX also must upgrade to the newest version. The
> problem is that
>
> if you upgrade the plugin, you should also upgrade the APISIX core. If the
>
> new version of the APISIX core is not compatible of the old
>
> APISIX core. How would you do it?
>
>
>
> When you are in a company and want to write a plugin for your privacy
> service.
>
> You should more careful to maintain you plugin about how to install,
> upgrade, etc.
>
> Everyone who writes the plugin for privacy service also will do what you
> have done.
>
> There are many duplicate works.
>
>
>
> When the user of the APISIX need some features, which may be developed by
> some other developer,
>
> how can we found in the web? cloning the APISIX repository and then search
> the plugin
>
> are not very effective and intuitive.
>
>
>
> What we should to do is separating the APISIX core implement and the
> plugin implement, introducing
>
> a plugin center registry, adding a new cli tool for managing plugin for
> installing, upgrading, removing,
>
> searching, etc, and must be in accordance with the sematic version rule
> both of the APISIX core and
>
> the plugin. If we do this, we could solved the above problems.
>
>
> *Detail*
>
> The following image show how to separate the APISIX core and the plugin.
>
>
> [image: image.png]
>
>
>
> 1. All the plugins will be placed the APISIX core subdirectory named
> "plugins", eg: If we install the APISIX in the path /opt/apisix, then
> all the plugins will be found in /opt/apisix/plugins
> 2. Every plugin has a unique directory name.
> 3. The plugin directory name should be in the form of
> {company|person}.{name}. {company|person} will be replaced with the
> company name or person developer name, *and the **{name}** is the
> current plugin name.* eg, current version of the APISIX have a plugin
> named basic-auth，which will be changed to apisix.basic-auth if
> applying the above rule.
> 4. Every plugin have an entry file for APISIX core searching, which
> named index.lua.The file index.lua will export _M table ,which is the
> same as before.
> 5. Extends the _M table description of the plugin.
>
>
> *The CLI*
>
> The system will be introduced a new command named a6. The following shows
> all subcommands and describes functions:
>
> - a6 install {company|person}.{name}: which will download
> {company|person}.{name} from the center registry and install the
> {company|person}.{name} to the plugins directory.
> - a6 search name will show all plugin's names and descriptions that is
> matched name
> - a6 list will list all installed plugins in the local system.
> - a6 init [{company|person}.{name}] will create a plugin directory
> with some templates file.
> - a6 push will push the current plugin directory to the remote center
> registry with an authenticated account.
>
>
> *The Center Registry*
>
> The center registry will have a public domain, so the a6 command will
> download the plugin from the domain by default.
>
> The center registry will have a search page, which may be shown as below:
>
> [image: image.png]
>
>
>
> If click the box, then show the detail page as below:
>
> [image: image.png]
>
>
>
>
> --
> DamonChen
>
>
>