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
