<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 5/21/2014 5:43 PM, Zhou Zheng Sheng
wrote:<br>
</div>
<blockquote cite="mid:537C7534.1050007@linux.vnet.ibm.com"
type="cite">
<pre wrap="">on 2014/05/21 14:48, Yu Xin Huo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 5/21/2014 9:22 AM, Sheldon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/20/2014 02:53 PM, Yu Xin Huo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Does that mean the user needs to find this file and uncomment these
codes when he want to try the plugin.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Kimchi does not provide any plugins other than "sample". All plugins are
third-party ones, the third-party plugins can be built outside the
Kimchi source code directory. So we don't need a command to select
plugins on build time.</pre>
</blockquote>
Stated in another reply, nothing related to build time.<br>
<blockquote cite="mid:537C7534.1050007@linux.vnet.ibm.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
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".
</pre>
</blockquote>
<pre wrap="">
"--enable-sample" command does not make any sense as no additional
overhead of coding should be writen for non production stuff.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
As I mentioned above. We don't need any build time command/switch/option
to enable plugins. In runtime, if the user want a plugin, just install
the RPM, or if the user dislike a installed plugin, he/she can edit
"pluginX.conf" or uninstall the plugin.</pre>
</blockquote>
Stated in another reply, nothing related to build time. All about
run-time.<br>
<blockquote cite="mid:537C7534.1050007@linux.vnet.ibm.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
I'd prefer --enable-sample to manual file coping.</pre>
</blockquote>
I have stated many times, "--enable-sample" is not good or bad, it
is <b>wrong</b>.<br>
<blockquote cite="mid:537C7534.1050007@linux.vnet.ibm.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
I would like to listen to whole Team's voice.
</pre>
</blockquote>
<pre wrap="">
I'd propose a new solution. Kimchi should always build the sample
plugin, but it neither install the sample plugin nor ship it. When we
run Kimchi from the source code directory, by default the sample plugin
is not enabled in runtime. We can set "enabled = False" in
"sample.conf". When anyone wants to test it, just set "enabled = True".
No other options needed for third-party plugins, since third-party
plugins build independently.</pre>
</blockquote>
For production, there is no such a problem about the sample as it
will not be packaged in the binary delivery.<br>
<br>
From this discussion, we see a real requirement to enable/disable a
deployed plugin.<br>
<br>
For development time, it make sense to leverage "sample.conf" which
looks like some typical technical person's style.<br>
For production time, it does not make sense at all for admin to
modify those ".conf" files. need to add a kimchi command to
enable/disable any plugin.<br>
<br>
<blockquote cite="mid:537C7534.1050007@linux.vnet.ibm.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
On 5/19/2014 5:31 PM, Yu Xin Huo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 5/17/2014 3:30 AM, <a class="moz-txt-link-abbreviated" href="mailto:shaohef@linux.vnet.ibm.com">shaohef@linux.vnet.ibm.com</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">From: ShaoHe Feng <a class="moz-txt-link-rfc2396E" href="mailto:shaohef@linux.vnet.ibm.com"><shaohef@linux.vnet.ibm.com></a>
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
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">
Signed-off-by: ShaoHe Feng <a class="moz-txt-link-rfc2396E" href="mailto:shaohef@linux.vnet.ibm.com"><shaohef@linux.vnet.ibm.com></a>
---
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"
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<pre wrap="">
--
Thanks and best regards!
Sheldon Feng(???)<a class="moz-txt-link-rfc2396E" href="mailto:shaohef@linux.vnet.ibm.com"><shaohef@linux.vnet.ibm.com></a>
IBM Linux Technology Center
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>