2:31 a.m.
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.
>
>
>>
>>