6:28 a.m.
On 5/21/2014 5:19 PM, Zhou Zheng Sheng wrote:
on 2014/05/21 14:31, Yu Xin Huo wrote:
> On 5/21/2014 11:27 AM, Zhou Zheng Sheng wrote:
>> on 2014/05/21 09:22, Sheldon wrote:
>>> On 05/20/2014 02:53 PM, Yu Xin Huo wrote:
>>>> Sample plugin has no difference from other plugins, it is wrong to
>>>> specially
>>>> design a command for that sample plugin.
>>>> A plugin should have a way to disable itself, I prefer the original
>>>> way to
>>>> disable a plugin like below.
>>>>
>>>> In plugin descriptor xml file, comment out all tabs, if no tabs is
>>>> defined,
>>>> then the plugin will not be loaded.
>>>> By this way, no special command is needed, no additional overhead in
>>>> coding is
>>>> needed.
>> @Yu Xin, Your idea of building plugins inside of Kimchi works for the
>> plugins that comes with Kimchi originally. However usually third-party
>> plugins should be able to build themselves separately and outside from
>> kimchi code repository. What Kimchi needs to do is just to discover the
>> build result of the pluginX and load it, regardless whether it contains
>> tabs or not.
>>
>> For example, to compile a Linux kernel module, all we need is some
>> kernel headers that describe the data structures used by the module
>> interface. We do not need the kernel source itself. I have a example
>> kimchi plugin that build outside of kimchi in this way. (We are working
>> on making it open-source.) After I build the plugin separately, I can
>> just copy the build result files to kimchi's plugins dir and it loads
>> automatically.
>>
>> We also do not enforce all plugins to contain tabs, because some plugins
>> can just extend the kimchi API. And the ".conf" file in the specific
>> plugin dir already contains a "enable = True/False" switch. There is
no
>> need to "comment out all tabs".
> Obviously, you mean that there are various types of plugins for kimchi.
> If there is a sample for each type of the plugins, no wonder there will
> need a command to enable/disable the sample for that type of plugin?
>
No, we don't need a command to enable the plugins in build time. The
third-party plugins are built without Kimchi code, and outside of Kimchi
source code directory. You can build Kimchi without any plugins then
publish "kimchi.rpm" package. Another developer builds a plugin
separately on a different machine in a different time and publish
"kimchi-pluginX.rpm". The user download all the RPMs and install.
As I said, Kimchi does not provide any plugins, so it does not need to
build any plugins, and we don't need any command to enable the plugins
in build time. All Kimchi knows is that it scans the plugins directory
in runtime and loads all plugins in the directory.
In case a third-party developer want to test his plugin without
generating and installing a RPM file, he can build the plugin
separately, then get Kimchi source code and build Kimchi, copy the
plugin build result to Kimchi source code plugins directory, then at
last run Kimchi from the source code directory.
> If I understand you correctly, you mentioned something like ".conf"
> which is configuration file for the plugin to enable/disable itself.
> I already stated in my previous mail, I prefer a way to get plugin to
> enable/disable itself.
You are mixing runtime and build time configurations. The "pluginX.conf"
file is for the runtime. After the a plugin is installed, it is enabled
by default. If the admin want to disable the plugin temporally, he can
edit the "pluginX.conf" file. The build time of the plugins is not
related to the build time of Kimchi.
All the discussion has *nothing* to do with
"build time" at all. It is
all about run-time about how kimchi handle plugin.
Please *stop* to get anything about "build time" involved to make things
confusing.
Anything that is not target for production(for example, the sample)
should *not* be built into the final binary delivery package.
For run-time, 2 scenarios, under development or staged into production
for operations.
As you said, the plugin can be installed separately as a binary package
on top of kimchi installation.
If the admin want to get rid of any installed plugin, he need a way to
disable it.
So there is a need to disable plugin. Either 1 or 2 below is ok.
1. Design a way for plugin to disable itself.
2. Kimchi provide a command to disable/enable any plugin.
>> @Shaohe, @Yu Xin, as a conclusion, we do not need to add any mechanisms
>> to define which plugin to build/load. In Kimchi upstream, all the new
>> features should be added to Kimchi itself, not to plugins. The plugins
>> are for third-party developers and they should build their plugins
>> separately. Only the sample plugin that serves as a example on how to
>> write plugins should be treated specially. So --enable-sample is just
>> enough, we don't draw the feet of a snake.
> Have a command "--enable-sample" specially for a shipped sample in
> source distribution is definitely wrong.
> There is no justification to have additional overhead in coding for
> non-product stuff.
>>
>>> Does that mean the user needs to find this file and uncomment these
>>> codes when
>>> he want to try the plugin.
>>>
>>> Usually, a user wants to add a new plugin, he can reference the
>>> sample plugin codes.
>>> He can try it first to how it works and then read the code to how he
>>> can make
>>> himself plugin.
>>>
>>> we can change "--enbale-plugins" to "--enable-sample".
>>> our switch command("--enable-sample") is also an example, ti tells
>>> user how he
>>> build a plugin with kimchi
>>> together if he just add one plugin.
>>>
>>> Also he can add "with" command for his plugins if he wants to add
>>> more than one
>>> plugin.
>>> such as:
>>> --with-plugins=plugin1,plugin2,plugin3
>>> The "with" command is similar to switch command, a plugin
developer
>>> can read
>>> the autotool document to
>>> learn more about it.
>>>
>>>
>>>>
>