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

[Yu Xin Huo]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140521/1ffc2bdd/attachment.html>