[Kimchi-devel] [PATCH V2 6/7] add an optional to toggle the sample plugin

[Yu Xin Huo]

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?

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.
>
> @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.
>>
>>
>>>
>>>