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

Yu Xin Huo huoyuxin at linux.vnet.ibm.com
Wed May 21 06:48:21 UTC 2014


On 5/21/2014 9:22 AM, 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.
> Does that mean the user needs to find this file and uncomment these 
> codes when he want to try the plugin.
Here, you are discussing usability. you can improve it, but here the 
design is to have a way to get the plugin to enable/disable itself.
>
> 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".

"--enable-sample" command does not make any sense as no additional 
overhead of coding should be writen for non production stuff.

> 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.
I figured out 3 designs which I think all are clean enough.  For your 
reference.

1. Design a way for the plugin to enable/disable itself.         -- the 
best from my point.
2. Design a command to enable/disable any plugins, plugin name can be a 
parameter.
     Sample plugin by default is disabled, it can be enabled as a plugin 
which has no difference to other plugins.
3. Move the sample plugin out of the plugins folder, if it need to be 
enabled, copy the sample folder to plugins folder, user can directly 
modify the sample to create their plugins.

I would like to listen to whole Team's voice.
>
>
>>
>>
>> On 5/19/2014 5:31 PM, Yu Xin Huo wrote:
>>> On 5/17/2014 3:30 AM, shaohef at linux.vnet.ibm.com wrote:
>>>> From: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
>>>>
>>>> sample plugin is used to test as a plugin demo.
>>>>
>>>> we disable it by default.
>>>>
>>>> use this command to enable sample plugin
>>>> $ ./autogen.sh --enable-plugins
>>> As this command is specially used to enable the sample plugin, so 
>>> the param of "enable-plugins" is quite confusing, looks like 
>>> enabling all the plugins.
>>> If it is only to enable that sample plugin, I do not think it is 
>>> worth to add such a command specially for that.
>>>>
>>>> Signed-off-by: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
>>>> ---
>>>>   configure.ac                                   | 10 ++++++++++
>>>>   plugins/sample/Makefile.am                     | 18 
>>>> +++++++++++++++++-
>>>>   plugins/sample/{sample.conf => sample.conf.in} |  2 +-
>>>>   3 files changed, 28 insertions(+), 2 deletions(-)
>>>>   rename plugins/sample/{sample.conf => sample.conf.in} (90%)
>>>>
>>>> diff --git a/configure.ac b/configure.ac
>>>> index cc971e8..ab1b302 100644
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -48,6 +48,16 @@ if test "x$PYFLAKES" = "x"; then
>>>>     AC_MSG_WARN([pyflakes not found])
>>>>   fi
>>>>
>>>> +AC_ARG_ENABLE(
>>>> +    [plugins],
>>>> +    [AS_HELP_STRING(
>>>> +        [--enable-plugins],
>>>> +        [build plugins packages @<:@default=no@:>@]
>>>> +    )],
>>>> +    ,
>>>> +    [enable_plugins="no"]
>>>> +)
>>>> +AM_CONDITIONAL([PLUGINS], [test "${enable_plugins}" = "yes"])
>>>>
>>>>   AC_CONFIG_FILES([
>>>>       po/Makefile.in
>>>> diff --git a/plugins/sample/Makefile.am b/plugins/sample/Makefile.am
>>>> index e03a4c0..b0beb32 100644
>>>> --- a/plugins/sample/Makefile.am
>>>> +++ b/plugins/sample/Makefile.am
>>>> @@ -19,4 +19,20 @@
>>>>
>>>>   SUBDIRS = ui
>>>>
>>>> -EXTRA_DIST = API.json sample.conf $(wildcard *.py)
>>>> +EXTRA_DIST = API.json sample.conf.in $(wildcard *.py)
>>>> +
>>>> +if PLUGINS
>>>> +ENABLE_PLUGINS =  True
>>>> +else
>>>> +ENABLE_PLUGINS =  False
>>>> +endif
>>>> +
>>>> +do_substitution = \
>>>> +    sed -e 's,[@]ENABLE_PLUGINS[@],$(ENABLE_PLUGINS),g'
>>>> +
>>>> +sample.conf: sample.conf.in Makefile
>>>> +    echo $(ENABLE_PLUGINS)
>>>> +    $(do_substitution) < $< > $@
>>>> +
>>>> +BUILT_SOURCES = sample.conf
>>>> +CLEANFILES = sample.conf
>>>> diff --git a/plugins/sample/sample.conf 
>>>> b/plugins/sample/sample.conf.in
>>>> similarity index 90%
>>>> rename from plugins/sample/sample.conf
>>>> rename to plugins/sample/sample.conf.in
>>>> index 78a9f4e..12a3eef 100644
>>>> --- a/plugins/sample/sample.conf
>>>> +++ b/plugins/sample/sample.conf.in
>>>> @@ -1,5 +1,5 @@
>>>>   [kimchi]
>>>> -enable = True
>>>> +enable = @ENABLE_PLUGINS@
>>>>   plugin_class = "Drawings"
>>>>   uri = "/plugins/sample"
>>>>
>>>
>>>
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
> -- 
> Thanks and best regards!
>
> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
> IBM Linux Technology Center

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


More information about the Kimchi-devel mailing list