[PATCH V2 0/7] Issue #342: load i18n.html of the plugin
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com> V1 -> V2: The improvement concept here is to directly generate JSON on the server and assign it to the i18n variable, rather than inserting nodes into the DOM. Plugins would use a plugin1.i18n= structure to keep plugin strings from colliding with each other, or with the kimchi variables. ShaoHe Feng (5): Update root.py to make Cheetah render the JSON template. Update the i18n tmpl to produce JSON Add JS API for fetching i18n JSON add an optional to toggle the sample plugin generate the translation files for plugins/sample Zhou Zheng Sheng (2): Add Minimal UI Page for the Sample Plugin Issue #342: load i18n.html of the plugin configure.ac | 11 +++ plugins/sample/Makefile.am | 25 ++++- plugins/sample/__init__.py | 3 +- plugins/sample/config.status | 1 + plugins/sample/po/LINGUAS | 1 + plugins/sample/po/Makefile.in.in | 1 + plugins/sample/po/Makevars | 1 + plugins/sample/po/POTFILES.in | 2 + plugins/sample/po/en_US.po | 21 ++++ plugins/sample/po/gen-pot | 1 + plugins/sample/po/pt_BR.po | 24 +++++ plugins/sample/po/zh_CN.po | 24 +++++ plugins/sample/sample.conf | 7 -- plugins/sample/sample.conf.in | 12 +++ plugins/sample/ui/config/tab-ext.xml | 9 +- plugins/sample/ui/pages/i18n.json.tmpl | 9 ++ plugins/sample/ui/pages/tab.html.tmpl | 6 ++ src/kimchi/root.py | 5 + src/kimchi/template.py | 34 ++++--- ui/js/src/kimchi.api.js | 18 +++- ui/js/src/kimchi.main.js | 24 ++++- ui/pages/i18n.html.tmpl | 176 --------------------------------- ui/pages/i18n.json.tmpl | 163 ++++++++++++++++++++++++++++++ 23 files changed, 368 insertions(+), 210 deletions(-) create mode 120000 plugins/sample/config.status create mode 120000 plugins/sample/po/LINGUAS create mode 120000 plugins/sample/po/Makefile.in.in create mode 120000 plugins/sample/po/Makevars create mode 100644 plugins/sample/po/POTFILES.in create mode 100644 plugins/sample/po/en_US.po create mode 120000 plugins/sample/po/gen-pot create mode 100644 plugins/sample/po/pt_BR.po create mode 100644 plugins/sample/po/zh_CN.po delete mode 100644 plugins/sample/sample.conf create mode 100644 plugins/sample/sample.conf.in create mode 100644 plugins/sample/ui/pages/i18n.json.tmpl create mode 100644 plugins/sample/ui/pages/tab.html.tmpl delete mode 100644 ui/pages/i18n.html.tmpl create mode 100644 ui/pages/i18n.json.tmpl -- 1.9.0
From: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> Add minimal UI just enough to re-produce issue 342. https://github.com/kimchi-project/kimchi/issues/342 Signed-off-by: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- plugins/sample/__init__.py | 3 ++- plugins/sample/sample.conf | 5 +++++ plugins/sample/ui/config/tab-ext.xml | 9 +++++---- plugins/sample/ui/pages/i18n.json.tmpl | 9 +++++++++ plugins/sample/ui/pages/tab.html.tmpl | 6 ++++++ 5 files changed, 27 insertions(+), 5 deletions(-) create mode 100644 plugins/sample/ui/pages/i18n.json.tmpl create mode 100644 plugins/sample/ui/pages/tab.html.tmpl diff --git a/plugins/sample/__init__.py b/plugins/sample/__init__.py index 3183898..2101aed 100644 --- a/plugins/sample/__init__.py +++ b/plugins/sample/__init__.py @@ -26,6 +26,7 @@ from cherrypy import expose from kimchi.config import PluginPaths from kimchi.control.base import Collection, Resource +from kimchi.root import Root from plugins.sample.i18n import messages from plugins.sample.model import Model @@ -33,7 +34,7 @@ from plugins.sample.model import Model model = Model() -class Drawings(Resource): +class Drawings(Root): def __init__(self): Resource.__init__(self, model) self.description = Description(model) diff --git a/plugins/sample/sample.conf b/plugins/sample/sample.conf index c4e80f7..78a9f4e 100644 --- a/plugins/sample/sample.conf +++ b/plugins/sample/sample.conf @@ -5,3 +5,8 @@ uri = "/plugins/sample" [/] tools.trailing_slash.on = False +tools.sessions.on = True +tools.sessions.name = 'kimchi' +tools.sessions.httponly = True +tools.sessions.locking = 'explicit' +tools.sessions.storage_type = 'ram' diff --git a/plugins/sample/ui/config/tab-ext.xml b/plugins/sample/ui/config/tab-ext.xml index 948fa07..b98c126 100644 --- a/plugins/sample/ui/config/tab-ext.xml +++ b/plugins/sample/ui/config/tab-ext.xml @@ -1,7 +1,8 @@ <?xml version="1.0" encoding="utf-8"?> -<!--<tabs-ext> +<tabs-ext> <tab> - <title>Test</title> - <filePath>plugins/sample/ui/tab.html</filePath> + <title>SampleTab</title> + <path>plugins/sample/tab.html</path> + <nls>plugins/sample/i18n.html</nls> </tab> -</tabs-ext>--> \ No newline at end of file +</tabs-ext> diff --git a/plugins/sample/ui/pages/i18n.json.tmpl b/plugins/sample/ui/pages/i18n.json.tmpl new file mode 100644 index 0000000..a153e2d --- /dev/null +++ b/plugins/sample/ui/pages/i18n.json.tmpl @@ -0,0 +1,9 @@ +#unicode UTF-8 +#import gettext +#from kimchi.cachebust import href +#silent t = gettext.translation($lang.domain, $lang.localedir, languages=$lang.lang) +#silent _ = t.gettext +#silent _t = t.gettext +{ + "SampleTab": "$_("SampleTab")" +} diff --git a/plugins/sample/ui/pages/tab.html.tmpl b/plugins/sample/ui/pages/tab.html.tmpl new file mode 100644 index 0000000..49fc4ec --- /dev/null +++ b/plugins/sample/ui/pages/tab.html.tmpl @@ -0,0 +1,6 @@ +<!DOCTYPE html> +<html> +<body> +Hello, world +</body> +</html> -- 1.9.0
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote:
From: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com>
Add minimal UI just enough to re-produce issue 342.
https://github.com/kimchi-project/kimchi/issues/342
Signed-off-by: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- plugins/sample/__init__.py | 3 ++- plugins/sample/sample.conf | 5 +++++ plugins/sample/ui/config/tab-ext.xml | 9 +++++---- plugins/sample/ui/pages/i18n.json.tmpl | 9 +++++++++ plugins/sample/ui/pages/tab.html.tmpl | 6 ++++++ 5 files changed, 27 insertions(+), 5 deletions(-) create mode 100644 plugins/sample/ui/pages/i18n.json.tmpl create mode 100644 plugins/sample/ui/pages/tab.html.tmpl
diff --git a/plugins/sample/__init__.py b/plugins/sample/__init__.py index 3183898..2101aed 100644 --- a/plugins/sample/__init__.py +++ b/plugins/sample/__init__.py @@ -26,6 +26,7 @@ from cherrypy import expose
from kimchi.config import PluginPaths from kimchi.control.base import Collection, Resource +from kimchi.root import Root from plugins.sample.i18n import messages from plugins.sample.model import Model
@@ -33,7 +34,7 @@ from plugins.sample.model import Model model = Model()
-class Drawings(Resource): +class Drawings(Root): def __init__(self): Resource.__init__(self, model) self.description = Description(model) diff --git a/plugins/sample/sample.conf b/plugins/sample/sample.conf index c4e80f7..78a9f4e 100644 --- a/plugins/sample/sample.conf +++ b/plugins/sample/sample.conf @@ -5,3 +5,8 @@ uri = "/plugins/sample"
[/] tools.trailing_slash.on = False +tools.sessions.on = True +tools.sessions.name = 'kimchi' +tools.sessions.httponly = True +tools.sessions.locking = 'explicit' +tools.sessions.storage_type = 'ram' diff --git a/plugins/sample/ui/config/tab-ext.xml b/plugins/sample/ui/config/tab-ext.xml index 948fa07..b98c126 100644 --- a/plugins/sample/ui/config/tab-ext.xml +++ b/plugins/sample/ui/config/tab-ext.xml @@ -1,7 +1,8 @@ <?xml version="1.0" encoding="utf-8"?> -<!--<tabs-ext> +<tabs-ext> <tab> - <title>Test</title> - <filePath>plugins/sample/ui/tab.html</filePath> + <title>SampleTab</title> + <path>plugins/sample/tab.html</path> + <nls>plugins/sample/i18n.html</nls> here, an nls tag is designed for user to specify which file is used for i18n content.
But go through ' [PATCH V2 5/7] Issue #342: load i18n.html of the plugin'. In javascript code, the path is hardcoded to be below /var pluginI18nUrl = 'plugins/{plugin}/i18n.json'; /If it is mandatory for a plugin to put i18n content to a file named i18n.html directly under the plugin folder. then remove that nls tag. Personally, as a plugin descriptor xml file is provided for a plugin developer to specify configuration of a plugin, I prefer to leave the nls tag there to give the plugin developer the freedom to put wherever the i18n file to be.
</tab> -</tabs-ext>--> \ No newline at end of file +</tabs-ext> diff --git a/plugins/sample/ui/pages/i18n.json.tmpl b/plugins/sample/ui/pages/i18n.json.tmpl new file mode 100644 index 0000000..a153e2d --- /dev/null +++ b/plugins/sample/ui/pages/i18n.json.tmpl @@ -0,0 +1,9 @@ +#unicode UTF-8 +#import gettext +#from kimchi.cachebust import href +#silent t = gettext.translation($lang.domain, $lang.localedir, languages=$lang.lang) +#silent _ = t.gettext +#silent _t = t.gettext +{ + "SampleTab": "$_("SampleTab")" +} diff --git a/plugins/sample/ui/pages/tab.html.tmpl b/plugins/sample/ui/pages/tab.html.tmpl new file mode 100644 index 0000000..49fc4ec --- /dev/null +++ b/plugins/sample/ui/pages/tab.html.tmpl @@ -0,0 +1,6 @@ +<!DOCTYPE html> +<html> +<body> +Hello, world +</body> +</html>
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com> when the request are json files, set the Content-Type as application/json. Signed-off-by: Adam King <rak@linux.vnet.ibm.com> Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- src/kimchi/root.py | 5 +++++ src/kimchi/template.py | 34 +++++++++++++++++++--------------- 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/src/kimchi/root.py b/src/kimchi/root.py index 8b1d09b..1cebfd1 100644 --- a/src/kimchi/root.py +++ b/src/kimchi/root.py @@ -82,6 +82,11 @@ class Root(Resource): def default(self, page, **kwargs): if page.endswith('.html'): return template.render(page, None) + if page.endswith('.json'): + cherrypy.response.headers['Content-Type'] = \ + 'application/json;charset=utf-8' + context = template.render_cheetah_file(page, None) + return context.encode("utf-8") raise cherrypy.HTTPError(404) @cherrypy.expose diff --git a/src/kimchi/template.py b/src/kimchi/template.py index 60cd818..146e735 100644 --- a/src/kimchi/template.py +++ b/src/kimchi/template.py @@ -82,26 +82,30 @@ def can_accept_html(): can_accept('*/*') +def render_cheetah_file(resource, data): + paths = cherrypy.request.app.root.paths + filename = paths.get_template_path(resource) + try: + params = {'data': data} + lang = validate_language(get_lang()) + gettext_conf = {'domain': 'kimchi', + 'localedir': paths.mo_dir, + 'lang': [lang]} + params['lang'] = gettext_conf + return Template(file=filename, searchList=params).respond() + except OSError, e: + if e.errno == errno.ENOENT: + raise cherrypy.HTTPError(404) + else: + raise + + def render(resource, data): if can_accept('application/json'): cherrypy.response.headers['Content-Type'] = \ 'application/json;charset=utf-8' return json.dumps(data, indent=2, separators=(',', ':')) elif can_accept_html(): - paths = cherrypy.request.app.root.paths - filename = paths.get_template_path(resource) - try: - params = {'data': data} - lang = validate_language(get_lang()) - gettext_conf = {'domain': 'kimchi', - 'localedir': paths.mo_dir, - 'lang': [lang]} - params['lang'] = gettext_conf - return Template(file=filename, searchList=params).respond() - except OSError, e: - if e.errno == errno.ENOENT: - raise cherrypy.HTTPError(404) - else: - raise + return render_cheetah_file(resource, data) else: raise cherrypy.HTTPError(406) -- 1.9.0
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com> Remove html tags from i18n as they are not valid Correct object definition from acceptable JS to valid JSON replacing ' with " in attribute names. Update root.py to make Cheetah render the JSON template. Signed-off-by: Adam King <rak@linux.vnet.ibm.com> Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- ui/pages/i18n.html.tmpl | 176 ------------------------------------------------ ui/pages/i18n.json.tmpl | 163 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+), 176 deletions(-) delete mode 100644 ui/pages/i18n.html.tmpl create mode 100644 ui/pages/i18n.json.tmpl diff --git a/ui/pages/i18n.html.tmpl b/ui/pages/i18n.html.tmpl deleted file mode 100644 index 98da828..0000000 --- a/ui/pages/i18n.html.tmpl +++ /dev/null @@ -1,176 +0,0 @@ -#* - * Project Kimchi - * - * Copyright IBM, Corp. 2013 - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - *# -#unicode UTF-8 -#import gettext -#from kimchi.cachebust import href -#silent t = gettext.translation($lang.domain, $lang.localedir, languages=$lang.lang) -#silent _ = t.gettext -#silent _t = t.gettext - -<!DOCTYPE html> -<html class="no-js" lang=$lang.lang[0]> -<head> - <meta charset="utf-8"> - <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> - <title>language</title> -</head> -<body> -<script> -var i18n = { - 'KCHAUTH6001E': "$_("The username or password you entered is incorrect. Please try again.")", - 'KCHAUTH6002E': "$_("This field is required.")", - - 'KCHAUTH6001M': "$_("Log in")", - 'KCHAUTH6002M': "$_("Logging in...")", - - 'Host': "$_("Host")", - 'Guests': "$_("Guests")", - 'Templates': "$_("Templates")", - 'Storage': "$_("Storage")", - 'Network': "$_("Network")", - - 'KCHAPI6001E': "$_("Invalid URL. Redireced to home page.")", - 'KCHAPI6002E': "$_("Failed to get application configuration")", - 'KCHAPI6003E': "$_("This is not a valid Linux path")", - 'KCHAPI6004E': "$_("This is not a valid URL.")", - 'KCHAPI6005E': "$_("No such data available.")", - 'KCHAPI6006E': "$_("options needed.")", - 'KCHAPI6007E': "$_("Can not contact the host system. Verify the host system is up and that you have network connectivity to it. HTTP request response %1. ")", - - 'KCHAPI6001M': "$_("Delete Confirmation")", - 'KCHAPI6002M': "$_("OK")", - 'KCHAPI6003M': "$_("Cancel")", - 'KCHAPI6004M': "$_("Confirm")", - 'KCHAPI6005M': "$_("Create")", - 'KCHAPI6006M': "$_("Warning")", - - 'KCHGRD6001M': "$_("Loading...")", - 'KCHGRD6002M': "$_("An error occurs while checking for packages update.")", - 'KCHGRD6003M': "$_("Retry")", - 'KCHGRD6004M': "$_("Detailed message:")", - - 'KCHTMPL6001W': "$_("No iso found")", - - 'KCHTMPL6002E': "$_("This is not a valid ISO file.")", - - 'KCHTMPL6002M': "$_("It will take long time. Do you want to continue?")", - 'KCHTMPL6003M': "$_("This will permanently delete the template. Would you like to continue?")", - - 'KCHHOST6001E': "$_("Unable to shut down system as there are some virtual machines running!")", - - 'KCHHOST6001M': "$_("Max:")", - 'KCHHOST6002M': "$_("Utilization")", - 'KCHHOST6003M': "$_("Available")", - 'KCHHOST6004M': "$_("Read Rate")", - 'KCHHOST6005M': "$_("Write Rate")", - 'KCHHOST6006M': "$_("Received")", - 'KCHHOST6007M': "$_("Sent")", - 'KCHHOST6008M': "$_("Shutting down or restarting host will cause unsaved work lost. Continue to shut down/restarting?")", - - - 'KCHREPO6001M': "$_("Confirm")", - 'KCHREPO6002M': "$_("Repository will be removed permanently and can't be recovered. Do you want to continue?")", - 'KCHREPO6003M': "$_("Repositories")", - 'KCHREPO6004M': "$_("ID")", - 'KCHREPO6005M': "$_("Name")", - 'KCHREPO6006M': "$_("Base URL")", - 'KCHREPO6007M': "$_("Is Mirror")", - 'KCHREPO6008M': "$_("URL Args")", - 'KCHREPO6009M': "$_("Enabled")", - 'KCHREPO6010M': "$_("GPG Check")", - 'KCHREPO6011M': "$_("GPG Key")", - 'KCHREPO6012M': "$_("Add")", - 'KCHREPO6013M': "$_("Edit")", - 'KCHREPO6014M': "$_("Remove")", - 'KCHREPO6015M': "$_("Failed.")", - 'KCHREPO6016M': "$_("Enable")", - 'KCHREPO6017M': "$_("Disable")", - - - 'KCHUPD6001M': "$_("Software Updates")", - 'KCHUPD6002M': "$_("Package Name")", - 'KCHUPD6003M': "$_("Version")", - 'KCHUPD6004M': "$_("Architecture")", - 'KCHUPD6005M': "$_("Repository")", - 'KCHUPD6006M': "$_("Update All")", - 'KCHUPD6007M': "$_("Updating...")", - 'KCHUPD6008M': "$_("Failed to retrieve updates.")", - 'KCHUPD6009M': "$_("Failed to update package(s).")", - - - 'KCHDR6001M': "$_("Debug report will be removed permanently and can't be recovered. Do you want to continue?")", - 'KCHDR6002M': "$_("Debug Reports")", - 'KCHDR6003M': "$_("Name")", - 'KCHDR6005M': "$_("Generated Time")", - 'KCHDR6006M': "$_("Generate")", - 'KCHDR6007M': "$_("Generating...")", - 'KCHDR6008M': "$_("Rename")", - 'KCHDR6009M': "$_("Remove")", - 'KCHDR6010M': "$_("Download")", - 'KCHDR6011M': "$_("Report name should contain only letters, digits and/or hyphen ('-').")", - - 'KCHVM6001M': "$_("This will delete the virtual machine and its virtual disks. This operation cannot be undone. Would you like to continue?")", - 'KCHVM6002M': "$_("Power off Confirmation")", - 'KCHVM6003M': "$_("This action may produce undesirable results, " - "for example unflushed disk cache in the guest. " - "Would you like to continue?")", - 'KCHVM6004M': "$_("Reset Confirmation")", - 'KCHVM6005M': "$_("There is a risk of data loss caused by reset without" - " the guest OS shutdown. Would you like to continue?")", - 'KCHVM6006M': "$_("Shut Down Confirmation")", - 'KCHVM6007M': "$_("Note the guest OS may ignore this request. Would you like to continue?")", - - 'KCHVMCD6001M': "$_("This CDROM will be detached permanently and you can re-attach it. Continue to detach it?")", - 'KCHVMCD6002M': "$_("Attach")", - 'KCHVMCD6003M': "$_("Attaching...")", - 'KCHVMCD6004M': "$_("Replace")", - 'KCHVMCD6005M': "$_("Replacing...")", - 'KCHVMCD6006M': "$_("Successfully attached!")", - 'KCHVMCD6007M': "$_("Successfully replaced!")", - 'KCHVMCD6008M': "$_("Successfully detached!")", - - - 'KCHNET6001E': "$_("The VLAN id must be between 1 and 4094.")", - - 'KCHNET6001M': "$_("unavailable")", - 'KCHNET6002M': "$_("This action will interrupt network connectivity for any virtual machine that depend on this network.")", - 'KCHNET6003M': "$_("Create a network")", - 'KCHNET6004M': "$_("This network is not persistent. Instead of stop, this action will permanently delete it. Would you like to continue?")", - - 'KCHPOOL6001M': "$_("This will permanently delete the storage pool. Would you like to continue?")", - 'KCHPOOL6002M': "$_("This storage pool is empty.")", - 'KCHPOOL6003M': "$_("It will format your disk and you will loose any data in there, are you sure to continue? ")", - 'KCHPOOL6004M': "$_("SCSI Fibre Channel")", - 'KCHPOOL6005M': "$_("No SCSI adapters found.")", - - 'KCHPOOL6001E': "$_("The storage pool name can not be blank.")", - 'KCHPOOL6002E': "$_("The storage pool path can not be blank.")", - 'KCHPOOL6003E': "$_("NFS server mount path can not be blank.")", - 'KCHPOOL6004E': "$_("Invalid storage pool name. It should not contain '/'.")", - 'KCHPOOL6005E': "$_("Invalid NFS mount path.")", - 'KCHPOOL6006E': "$_("No logical device selected.")", - 'KCHPOOL6007E': "$_("The iSCSI target can not be blank.")", - 'KCHPOOL6008E': "$_("Server name can not be blank.")", - 'KCHPOOL6009E': "$_("This is not a valid Server Name or IP. please, modify it.")", - 'KCHPOOL6010M': "$_("Looking for available partitions ...")", - 'KCHPOOL6011M': "$_("No available partitions found.")", - 'KCHPOOL6012M': "$_("This storage pool is not persistent. Instead of deactivate, this action will permanently delete it. Would you like to continue?")" -}; -</script> -</body> -</html> diff --git a/ui/pages/i18n.json.tmpl b/ui/pages/i18n.json.tmpl new file mode 100644 index 0000000..2f6ef73 --- /dev/null +++ b/ui/pages/i18n.json.tmpl @@ -0,0 +1,163 @@ +#* + * Project Kimchi + * + * Copyright IBM, Corp. 2013 + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + *# +#unicode UTF-8 +#import gettext +#from kimchi.cachebust import href +#silent t = gettext.translation($lang.domain, $lang.localedir, languages=$lang.lang) +#silent _ = t.gettext +#silent _t = t.gettext +{ + "KCHAUTH6001E": "$_("The username or password you entered is incorrect. Please try again.")", + "KCHAUTH6002E": "$_("This field is required.")", + + "KCHAUTH6001M": "$_("Log in")", + "KCHAUTH6002M": "$_("Logging in...")", + + "Host": "$_("Host")", + "Guests": "$_("Guests")", + "Templates": "$_("Templates")", + "Storage": "$_("Storage")", + "Network": "$_("Network")", + + "KCHAPI6001E": "$_("Invalid URL. Redireced to home page.")", + "KCHAPI6002E": "$_("Failed to get application configuration")", + "KCHAPI6003E": "$_("This is not a valid Linux path")", + "KCHAPI6004E": "$_("This is not a valid URL.")", + "KCHAPI6005E": "$_("No such data available.")", + "KCHAPI6006E": "$_("options needed.")", + "KCHAPI6007E": "$_("Can not contact the host system. Verify the host system is up and that you have network connectivity to it. HTTP request response %1. ")", + + "KCHAPI6001M": "$_("Delete Confirmation")", + "KCHAPI6002M": "$_("OK")", + "KCHAPI6003M": "$_("Cancel")", + "KCHAPI6004M": "$_("Confirm")", + "KCHAPI6005M": "$_("Create")", + "KCHAPI6006M": "$_("Warning")", + + "KCHGRD6001M": "$_("Loading...")", + "KCHGRD6002M": "$_("An error occurs while checking for packages update.")", + "KCHGRD6003M": "$_("Retry")", + "KCHGRD6004M": "$_("Detailed message:")", + + "KCHTMPL6001W": "$_("No iso found")", + + "KCHTMPL6002E": "$_("This is not a valid ISO file.")", + + "KCHTMPL6002M": "$_("It will take long time. Do you want to continue?")", + "KCHTMPL6003M": "$_("This will permanently delete the template. Would you like to continue?")", + + "KCHHOST6001E": "$_("Unable to shut down system as there are some virtual machines running!")", + + "KCHHOST6001M": "$_("Max:")", + "KCHHOST6002M": "$_("Utilization")", + "KCHHOST6003M": "$_("Available")", + "KCHHOST6004M": "$_("Read Rate")", + "KCHHOST6005M": "$_("Write Rate")", + "KCHHOST6006M": "$_("Received")", + "KCHHOST6007M": "$_("Sent")", + "KCHHOST6008M": "$_("Shutting down or restarting host will cause unsaved work lost. Continue to shut down/restarting?")", + + + "KCHREPO6001M": "$_("Confirm")", + "KCHREPO6002M": "$_("Repository will be removed permanently and can't be recovered. Do you want to continue?")", + "KCHREPO6003M": "$_("Repositories")", + "KCHREPO6004M": "$_("ID")", + "KCHREPO6005M": "$_("Name")", + "KCHREPO6006M": "$_("Base URL")", + "KCHREPO6007M": "$_("Is Mirror")", + "KCHREPO6008M": "$_("URL Args")", + "KCHREPO6009M": "$_("Enabled")", + "KCHREPO6010M": "$_("GPG Check")", + "KCHREPO6011M": "$_("GPG Key")", + "KCHREPO6012M": "$_("Add")", + "KCHREPO6013M": "$_("Edit")", + "KCHREPO6014M": "$_("Remove")", + "KCHREPO6015M": "$_("Failed.")", + "KCHREPO6016M": "$_("Enable")", + "KCHREPO6017M": "$_("Disable")", + + + "KCHUPD6001M": "$_("Software Updates")", + "KCHUPD6002M": "$_("Package Name")", + "KCHUPD6003M": "$_("Version")", + "KCHUPD6004M": "$_("Architecture")", + "KCHUPD6005M": "$_("Repository")", + "KCHUPD6006M": "$_("Update All")", + "KCHUPD6007M": "$_("Updating...")", + "KCHUPD6008M": "$_("Failed to retrieve updates.")", + "KCHUPD6009M": "$_("Failed to update package(s).")", + + + "KCHDR6001M": "$_("Debug report will be removed permanently and can't be recovered. Do you want to continue?")", + "KCHDR6002M": "$_("Debug Reports")", + "KCHDR6003M": "$_("Name")", + "KCHDR6005M": "$_("Generated Time")", + "KCHDR6006M": "$_("Generate")", + "KCHDR6007M": "$_("Generating...")", + "KCHDR6008M": "$_("Rename")", + "KCHDR6009M": "$_("Remove")", + "KCHDR6010M": "$_("Download")", + "KCHDR6011M": "$_("Report name should contain only letters, digits and/or hyphen ('-').")", + + "KCHVM6001M": "$_("This will delete the virtual machine and its virtual disks. This operation cannot be undone. Would you like to continue?")", + "KCHVM6002M": "$_("Power off Confirmation")", + "KCHVM6003M": "$_("This action may produce undesirable results, " + "for example unflushed disk cache in the guest. " + "Would you like to continue?")", + "KCHVM6004M": "$_("Reset Confirmation")", + "KCHVM6005M": "$_("There is a risk of data loss caused by reset without" + " the guest OS shutdown. Would you like to continue?")", + "KCHVM6006M": "$_("Shut Down Confirmation")", + "KCHVM6007M": "$_("Note the guest OS may ignore this request. Would you like to continue?")", + + "KCHVMCD6001M": "$_("This CDROM will be detached permanently and you can re-attach it. Continue to detach it?")", + "KCHVMCD6002M": "$_("Attach")", + "KCHVMCD6003M": "$_("Attaching...")", + "KCHVMCD6004M": "$_("Replace")", + "KCHVMCD6005M": "$_("Replacing...")", + "KCHVMCD6006M": "$_("Successfully attached!")", + "KCHVMCD6007M": "$_("Successfully replaced!")", + "KCHVMCD6008M": "$_("Successfully detached!")", + + + "KCHNET6001E": "$_("The VLAN id must be between 1 and 4094.")", + + "KCHNET6001M": "$_("unavailable")", + "KCHNET6002M": "$_("This action will interrupt network connectivity for any virtual machine that depend on this network.")", + "KCHNET6003M": "$_("Create a network")", + "KCHNET6004M": "$_("This network is not persistent. Instead of stop, this action will permanently delete it. Would you like to continue?")", + + "KCHPOOL6001M": "$_("This will permanently delete the storage pool. Would you like to continue?")", + "KCHPOOL6002M": "$_("This storage pool is empty.")", + "KCHPOOL6003M": "$_("It will format your disk and you will loose any data in there, are you sure to continue? ")", + "KCHPOOL6004M": "$_("SCSI Fibre Channel")", + "KCHPOOL6005M": "$_("No SCSI adapters found.")", + + "KCHPOOL6001E": "$_("The storage pool name can not be blank.")", + "KCHPOOL6002E": "$_("The storage pool path can not be blank.")", + "KCHPOOL6003E": "$_("NFS server mount path can not be blank.")", + "KCHPOOL6004E": "$_("Invalid storage pool name. It should not contain '/'.")", + "KCHPOOL6005E": "$_("Invalid NFS mount path.")", + "KCHPOOL6006E": "$_("No logical device selected.")", + "KCHPOOL6007E": "$_("The iSCSI target can not be blank.")", + "KCHPOOL6008E": "$_("Server name can not be blank.")", + "KCHPOOL6009E": "$_("This is not a valid Server Name or IP. please, modify it.")", + "KCHPOOL6010M": "$_("Looking for available partitions ...")", + "KCHPOOL6011M": "$_("No available partitions found.")", + "KCHPOOL6012M": "$_("This storage pool is not persistent. Instead of deactivate, this action will permanently delete it. Would you like to continue?")" +} -- 1.9.0
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com> Create an API for fetching the i18n JSON. Use the API to load the kimchi UI strings. API will need to be simplified after convincing CherryPy to respond to the reque st for JSON. Signed-off-by: Adam King <rak@linux.vnet.ibm.com> Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- ui/js/src/kimchi.api.js | 14 ++++++++++++++ ui/js/src/kimchi.main.js | 11 ++++++++--- 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/ui/js/src/kimchi.api.js b/ui/js/src/kimchi.api.js index 7d85fdf..19557c6 100644 --- a/ui/js/src/kimchi.api.js +++ b/ui/js/src/kimchi.api.js @@ -63,6 +63,20 @@ var kimchi = { }, /** + * Get the i18 strings. + */ + getI18n: function(suc, err, url, sync) { + kimchi.requestJSON({ + url : url ? url : kimchi.url + 'i18n.json', + type : 'GET', + resend: true, + dataType : 'json', + success : suc, + error: err + }); + }, + + /** * Get the host static information. */ getHost: function(suc, err) { diff --git a/ui/js/src/kimchi.main.js b/ui/js/src/kimchi.main.js index 86fed5b..3b130d0 100644 --- a/ui/js/src/kimchi.main.js +++ b/ui/js/src/kimchi.main.js @@ -247,9 +247,14 @@ kimchi.main = function() { }; // Load i18n translation strings first and then render the page. - $('#main').load('i18n.html', function() { - buildTabs(initUI); - }); + kimchi.getI18n( + function(i18nStrings){ //success + i18n=i18nStrings; + buildTabs(initUI); + }, + function(data){ //error + kimchi.message.error(data.responseJSON.reason); + }); }; kimchi.getHelp = function(e) { -- 1.9.0
From: Zhou Zheng Sheng <zhshzhou@linux.vnet.ibm.com> Apparently, in plugin code there is no way to insert new entries into Kimchi ./ui/pages/i18n.json.tmpl, so every plugin should provide its own i18n.json.tmpl. each plugin provides a "plugins/plugin-name/ui/pages/i18n.json.tmpl", and maps it to the URI "plugins/plugin-name/json.html". This is already supported by the kimchi back-end. What we have to do is just to load "plugins/plugin-name/i18n.json" in the front-end code. Signed-off-by: Adam King <rak@linux.vnet.ibm.com> Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- ui/js/src/kimchi.api.js | 4 +++- ui/js/src/kimchi.main.js | 13 +++++++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/ui/js/src/kimchi.api.js b/ui/js/src/kimchi.api.js index 19557c6..85bb1b8 100644 --- a/ui/js/src/kimchi.api.js +++ b/ui/js/src/kimchi.api.js @@ -71,6 +71,7 @@ var kimchi = { type : 'GET', resend: true, dataType : 'json', + async : !sync, success : suc, error: err }); @@ -572,13 +573,14 @@ var kimchi = { }); }, - listPlugins : function(suc, err) { + listPlugins : function(suc, err, sync) { kimchi.requestJSON({ url : kimchi.url + 'plugins', type : 'GET', contentType : 'application/json', dataType : 'json', resend: true, + async : !sync, success : suc, error : err }); diff --git a/ui/js/src/kimchi.main.js b/ui/js/src/kimchi.main.js index 3b130d0..44f6a68 100644 --- a/ui/js/src/kimchi.main.js +++ b/ui/js/src/kimchi.main.js @@ -39,7 +39,7 @@ kimchi.main = function() { $(xmlData).find('tab').each(function() { var $tab = $(this); var titleKey = $tab.find('title').text(); - var title = i18n[titleKey]; + var title = i18n[titleKey] ? i18n[titleKey] : titleKey; var path = $tab.find('path').text(); tabs.push({ title: title, @@ -64,6 +64,7 @@ kimchi.main = function() { var tabConfigUrl = '/config/ui/tabs.xml'; var pluginConfigUrl = '/plugins/{plugin}/ui/config/tab-ext.xml'; + var pluginI18nUrl = 'plugins/{plugin}/i18n.json'; var DEFAULT_HASH; var buildTabs = function(callback) { var tabs = retrieveTabs(tabConfigUrl); @@ -72,6 +73,12 @@ kimchi.main = function() { var url = kimchi.template(pluginConfigUrl, { plugin: p }); + var i18nUrl = kimchi.template(pluginI18nUrl, { + plugin: p + }); + kimchi.getI18n(function(i18nObj){ $.extend(i18n, i18nObj)}, + function(i18nObj){ //i18n is not define by plugin + }, i18nUrl, true); tabs.push.apply(tabs, retrieveTabs(url)); }); @@ -85,7 +92,9 @@ kimchi.main = function() { $('#nav-menu').append(genTabs(tabs)); callback && callback(); - }); + }, function(data) { + kimchi.message.error(data.responseJSON.reason); + }, true); }; var onLanguageChanged = function(lang) { -- 1.9.0
From: ShaoHe Feng <shaohef@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 Signed-off-by: ShaoHe Feng <shaohef@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" -- 1.9.0
From: ShaoHe Feng <shaohef@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
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote: 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@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"
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. On 5/19/2014 5:31 PM, Yu Xin Huo wrote:
From: ShaoHe Feng <shaohef@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
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote: 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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.
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.
On 5/19/2014 5:31 PM, Yu Xin Huo wrote:
From: ShaoHe Feng <shaohef@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
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote: 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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". @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.
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.
On 5/21/2014 11:27 AM, Zhou Zheng Sheng 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
on 2014/05/21 09:22, Sheldon wrote: 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.
on 2014/05/21 14:31, Yu Xin Huo wrote:
On 5/21/2014 11:27 AM, Zhou Zheng Sheng 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
on 2014/05/21 09:22, Sheldon wrote: 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.
@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.
-- Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
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 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
on 2014/05/21 09:22, Sheldon wrote: 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.
on 2014/05/21 18:28, Yu Xin Huo wrote:
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 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
on 2014/05/21 09:22, Sheldon wrote: 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.
This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin. As regard to runtime configuration, manually changing "enabled = False/True" is enough. For now the only valid use case to enable and disable a plugin is that a plugin developer experimenting some new things on the "sample", and this case is rare. I think there's little value to add new command for a rare case. Notice that even the third-party developers do not need to toggle the sample plugin, and only when we want to extend the plugin framework itself, we have to enable the sample and test it. So this use case is really rare. In all, "--enable-sample" is an acceptable solution for the developer to toggle the sample plugin occasionally in the developing environment. It's also acceptable that we don't have any switches or options at all, and the "enabled = False" is the default in "sample.conf". Whenever the developer wants to experiment something, just manually edit it and restart Kimchi back-end server.
Anything that is not target for production(for example, the sample) should *not* be built into the final binary delivery package.
True, the sample plugin didn't, doesn't and won't be in the binary package. The switch in this patch is just to toggle its availability when developer runs Kimchi from source code.
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.
If the user does not want a plugin, he can just uninstalls 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.
On 5/21/2014 11:09 PM, Zhou Zheng Sheng wrote:
on 2014/05/21 18:28, Yu Xin Huo wrote:
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 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
on 2014/05/21 09:22, Sheldon wrote: 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. This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin. Already stated that, sample are non-production stuff that should *never* be built into binary delivery package. So no matter whether you enable/disable the sample plugin, it should be left out from binary delivery package.
If the command itself is only for build time, the command itself should not be shipped in binary delivery package. For the content of binary delivery, it is determined by the packaging/distribution strategy, it has nothing to do with whether a plugin is enabled or disabled. A by default disabled plugin can also be shipped in final delivery The concept to connect "enable/disable plugin" to "the content of build output" itself does not make any sense. Sample will only be of significance at development time and at run-time.
As regard to runtime configuration, manually changing "enabled = False/True" is enough. For now the only valid use case to enable and disable a plugin is that a plugin developer experimenting some new things on the "sample", and this case is rare. I think there's little value to add new command for a rare case. Notice that even the third-party developers do not need to toggle the sample plugin, and only when we want to extend the plugin framework itself, we have to enable the sample and test it. So this use case is really rare. Again, for runtime,
For development, it is ok to modify some config file because it just follow *my original design* that "*plugin should have a way to disable itself*". For production operations, it is *not* ok for admin to modify the config file, a command is required at runtime to enable/disable plugin which is shipped in binary delivery package.
In all, "--enable-sample" is an acceptable solution for the developer to toggle the sample plugin occasionally in the developing environment. It's also acceptable that we don't have any switches or options at all, and the "enabled = False" is the default in "sample.conf". Whenever the developer wants to experiment something, just manually edit it and restart Kimchi back-end server.
Stated above, For development, no additional command is needed at all, if I understand you correctly, there is already a way for plugin to disable itself. For the "--enable-sample" command itself, there is no reason to design a command specially for a sample and it need additional handling to leave it out from binary delivery.
Anything that is not target for production(for example, the sample) should *not* be built into the final binary delivery package. True, the sample plugin didn't, doesn't and won't be in the binary package. The switch in this patch is just to toggle its availability when developer runs Kimchi from source code.
I am a bit confused here. Here, seems like here you mean that the 'switch' is for run-time. At the beginning, you said below, the 'switch' is for build time. /This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin./ No matter whether you mean run-time or build-time, stated above, sample should *never* be built into binary package, a *switch* is not needed at all.
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. If the user does not want a plugin, he can just uninstalls it.
For functionality completeness, a plugin can be installed/uninstalled/enabled/disabled like firebug
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.
on 2014/05/22 13:44, Yu Xin Huo wrote:
On 5/21/2014 11:09 PM, Zhou Zheng Sheng wrote:
on 2014/05/21 18:28, Yu Xin Huo wrote:
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. This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin. Already stated that, sample are non-production stuff that should *never* be built into binary delivery package. So no matter whether you enable/disable the sample plugin, it should be left out from binary delivery package.
If the command itself is only for build time, the command itself should not be shipped in binary delivery package.
For the content of binary delivery, it is determined by the packaging/distribution strategy, it has nothing to do with whether a plugin is enabled or disabled. A by default disabled plugin can also be shipped in final delivery
The concept to connect "enable/disable plugin" to "the content of build output" itself does not make any sense. Sample will only be of significance at development time and at run-time.
As regard to runtime configuration, manually changing "enabled = False/True" is enough. For now the only valid use case to enable and disable a plugin is that a plugin developer experimenting some new things on the "sample", and this case is rare. I think there's little value to add new command for a rare case. Notice that even the third-party developers do not need to toggle the sample plugin, and only when we want to extend the plugin framework itself, we have to enable the sample and test it. So this use case is really rare. Again, for runtime,
For development, it is ok to modify some config file because it just follow *my original design* that "*plugin should have a way to disable itself*". For production operations, it is *not* ok for admin to modify the config file, a command is required at runtime to enable/disable plugin which is shipped in binary delivery package.
In all, "--enable-sample" is an acceptable solution for the developer to toggle the sample plugin occasionally in the developing environment. It's also acceptable that we don't have any switches or options at all, and the "enabled = False" is the default in "sample.conf". Whenever the developer wants to experiment something, just manually edit it and restart Kimchi back-end server.
Stated above,
For development, no additional command is needed at all, if I understand you correctly, there is already a way for plugin to disable itself. For the "--enable-sample" command itself, there is no reason to design a command specially for a sample and it need additional handling to leave it out from binary delivery.
Anything that is not target for production(for example, the sample) should *not* be built into the final binary delivery package. True, the sample plugin didn't, doesn't and won't be in the binary package. The switch in this patch is just to toggle its availability when developer runs Kimchi from source code.
I am a bit confused here.
Here, seems like here you mean that the 'switch' is for run-time.
At the beginning, you said below, the 'switch' is for build time.
/This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin./
No matter whether you mean run-time or build-time, stated above, sample should *never* be built into binary package, a *switch* is not needed at all.
Installing a binary package and start Kimchi server is runtime, building Kimchi from source code and starting Kimchi server in place without installation is also runtime. The latter runtime is use by developers to speed up "write -> test -> debug -> write" cycle. The current build script doesn't package the sample plugin. The only case you want a sample plugin is to build and run Kimchi directly from source code directory and experimenting some new staffs against the plugin framework itself. This type of activity is rare even when we developing Kimchi and plugins. So by default the sample plugin is disabled, and we don't see it even when Kimchi is started in place to test our daily development changes. This "--enable-sample" option is given to the build scripts just to toggle default the availability setting in "sample.conf", and "sample.conf" is read by Kimchi in runtime. In other words, this build time switch is to toggle the default availability in runtime. Since we didn't change the shipping related build scripts, this "--enable-sample" only affects the Kimchi server started in place in runtime. In all, it's for the "development time", and it's not related to packaging. Having a build time switch for this is just for developers convenience. Considering functionally completeness, it's true that powerful software such as Firefox, Jenkins-ci and Linux kernel provide every operation to install, load and unload a module. This makes sense only when the project core features reach a high completeness, and the core developers decides to enable third-party developers to build some add-ons. Look at the github issues, Kimchi itself is far from complete. People use for its HTML5 accessibility and easy management of the virtualization, not for its plugins, and there is no third-party plugin in public at all. Frankly speaking, Kimchi for now is far from virt-manager. While there is a lot work to do for the core features, the "just works" plugin framework is just enough. The requirements for managing plugins are just synthetic ones. As I mentioned, the only valid use case for now is just experimenting new things on plugin framework itself. Each task and requirement should be prioritized and the project progresses step by step. Each task also has its own border, and it does not solve everything. I think for #Issue 342, this 7 patch series has already gone too far. If we keep asking completeness, this task would never finish. I can accept the current solution in this stage. The switch make sense and practical. I can also accept that don't have any switch at all because the usage is rare. If you have a lot better ideas beyond #Issue 342, you can always start a new mail thread, describe your design, write RFC patches, but that does not affect the validity of this patch. A fully functional plugin management system can be added later after we acknowledge the current progress.
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. If the user does not want a plugin, he can just uninstalls it.
For functionality completeness, a plugin can be installed/uninstalled/enabled/disabled like firebug
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.
-- Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
On 5/22/2014 2:53 PM, Zhou Zheng Sheng wrote:
On 5/21/2014 11:09 PM, Zhou Zheng Sheng wrote:
on 2014/05/21 18:28, Yu Xin Huo wrote:
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. This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin. Already stated that, sample are non-production stuff that should *never* be built into binary delivery package. So no matter whether you enable/disable the sample plugin, it should be left out from binary delivery package.
If the command itself is only for build time, the command itself should not be shipped in binary delivery package.
For the content of binary delivery, it is determined by the packaging/distribution strategy, it has nothing to do with whether a plugin is enabled or disabled. A by default disabled plugin can also be shipped in final delivery
The concept to connect "enable/disable plugin" to "the content of build output" itself does not make any sense. Sample will only be of significance at development time and at run-time.
As regard to runtime configuration, manually changing "enabled = False/True" is enough. For now the only valid use case to enable and disable a plugin is that a plugin developer experimenting some new things on the "sample", and this case is rare. I think there's little value to add new command for a rare case. Notice that even the third-party developers do not need to toggle the sample plugin, and only when we want to extend the plugin framework itself, we have to enable the sample and test it. So this use case is really rare. Again, for runtime,
For development, it is ok to modify some config file because it just follow *my original design* that "*plugin should have a way to disable itself*". For production operations, it is *not* ok for admin to modify the config file, a command is required at runtime to enable/disable plugin which is shipped in binary delivery package.
In all, "--enable-sample" is an acceptable solution for the developer to toggle the sample plugin occasionally in the developing environment. It's also acceptable that we don't have any switches or options at all, and the "enabled = False" is the default in "sample.conf". Whenever the developer wants to experiment something, just manually edit it and restart Kimchi back-end server. Stated above,
For development, no additional command is needed at all, if I understand you correctly, there is already a way for plugin to disable itself. For the "--enable-sample" command itself, there is no reason to design a command specially for a sample and it need additional handling to leave it out from binary delivery.
Anything that is not target for production(for example, the sample) should *not* be built into the final binary delivery package. True, the sample plugin didn't, doesn't and won't be in the binary package. The switch in this patch is just to toggle its availability when developer runs Kimchi from source code. I am a bit confused here.
Here, seems like here you mean that the 'switch' is for run-time.
At the beginning, you said below, the 'switch' is for build time.
/This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin./
No matter whether you mean run-time or build-time, stated above, sample should *never* be built into binary package, a *switch* is not needed at all. Installing a binary package and start Kimchi server is runtime, building Kimchi from source code and starting Kimchi server in place without installation is also runtime. The latter runtime is use by developers to speed up "write -> test -> debug -> write" cycle. The current build
on 2014/05/22 13:44, Yu Xin Huo wrote: script doesn't package the sample plugin. The only case you want a sample plugin is to build and run Kimchi directly from source code directory and experimenting some new staffs against the plugin framework itself. This type of activity is rare even when we developing Kimchi and plugins. So by default the sample plugin is disabled, and we don't see it even when Kimchi is started in place to test our daily development changes. This "--enable-sample" option is given to the build scripts just to toggle default the availability setting in "sample.conf", and "sample.conf" is read by Kimchi in runtime. In other words, this build time switch is to toggle the default availability in runtime. Since we didn't change the shipping related build scripts, this "--enable-sample" only affects the Kimchi server started in place in runtime. In all, it's for the "development time", and it's not related to packaging. Having a build time switch for this is just for developers convenience.
Considering functionally completeness, it's true that powerful software such as Firefox, Jenkins-ci and Linux kernel provide every operation to install, load and unload a module. This makes sense only when the project core features reach a high completeness, and the core developers decides to enable third-party developers to build some add-ons. Look at the github issues, Kimchi itself is far from complete. People use for its HTML5 accessibility and easy management of the virtualization, not for its plugins, and there is no third-party plugin in public at all. Frankly speaking, Kimchi for now is far from virt-manager. While there is a lot work to do for the core features, the "just works" plugin framework is just enough. The requirements for managing plugins are just synthetic ones. As I mentioned, the only valid use case for now is just experimenting new things on plugin framework itself.
Each task and requirement should be prioritized and the project progresses step by step. Each task also has its own border, and it does not solve everything. I think for #Issue 342, this 7 patch series has already gone too far. If we keep asking completeness, this task would never finish. I can accept the current solution in this stage. The switch make sense and practical. I can also accept that don't have any switch at all because the usage is rare. If you have a lot better ideas beyond #Issue 342, you can always start a new mail thread, describe your design, write RFC patches, but that does not affect the validity of this patch. A fully functional plugin management system can be added later after we acknowledge the current progress. If I read your words correctly, the conclusion got shaped.
1. Never get sample plugin included in binary delivery package. 2. Remove those commands like "enable-sample", "enable-plugins", use "sample.conf" to enable/disable plugin. Be default, disable sample plugin. As enable/disable plugin for production operations is not a requirement from real client feedback, so I am ok to leave that out currently. Shaohe, on top of this, please evaluate whether a readme is needed for a predictable experience.
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. If the user does not want a plugin, he can just uninstalls it. For functionality completeness, a plugin can be installed/uninstalled/enabled/disabled like firebug
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.
On 5/21/2014 11:09 PM, Zhou Zheng Sheng wrote:
on 2014/05/21 18:28, Yu Xin Huo wrote:
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 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
on 2014/05/21 09:22, Sheldon wrote: 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. This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin. Already stated that, sample are non-production stuff that should *never* be built into binary delivery package. So no matter whether you enable/disable the sample plugin, it should be left out from binary delivery package.
If the command itself is only for build time, the command itself should not be shipped in binary delivery package. For the content of binary delivery, it is determined by the packaging/distribution strategy, it has nothing to do with whether a plugin is enabled or disabled. A by default disabled plugin can also be shipped in final delivery The concept to connect "enable/disable plugin" to "the content of build output" itself does not make any sense. Sample will only be of significance at development time and at run-time.
As regard to runtime configuration, manually changing "enabled = False/True" is enough. For now the only valid use case to enable and disable a plugin is that a plugin developer experimenting some new things on the "sample", and this case is rare. I think there's little value to add new command for a rare case. Notice that even the third-party developers do not need to toggle the sample plugin, and only when we want to extend the plugin framework itself, we have to enable the sample and test it. So this use case is really rare. Again, for runtime,
For development, it is ok to modify some config file because it just follow *my original design* that "*plugin should have a way to disable itself*". For production operations, it is *not* ok for admin to modify the config file, a command is required at runtime to enable/disable plugin which is shipped in binary delivery package.
In all, "--enable-sample" is an acceptable solution for the developer to toggle the sample plugin occasionally in the developing environment. It's also acceptable that we don't have any switches or options at all, and the "enabled = False" is the default in "sample.conf". Whenever the developer wants to experiment something, just manually edit it and restart Kimchi back-end server. Stated above,
For development, no additional command is needed at all, if I understand you correctly, there is already a way for plugin to disable itself. For the "--enable-sample" command itself, there is no reason to design a command specially for a sample and it need additional handling to leave it out from binary delivery.
Anything that is not target for production(for example, the sample) should *not* be built into the final binary delivery package. True, the sample plugin didn't, doesn't and won't be in the binary package. The switch in this patch is just to toggle its availability when developer runs Kimchi from source code. I am a bit confused here.
Here, seems like here you mean that the 'switch' is for run-time. At the beginning, you said below, the 'switch' is for build time. /This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin./ No matter whether you mean run-time or build-time, stated above, sample should *never* be built into binary package, a *switch* is not needed at all.
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. If the user does not want a plugin, he can just uninstalls it. For functionality completeness, a plugin can be installed/uninstalled/enabled/disabled like firebug 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.
on 2014/05/22 13:57, Yu Xin Huo wrote:
On 5/21/2014 11:09 PM, Zhou Zheng Sheng wrote:
on 2014/05/21 18:28, Yu Xin Huo wrote:
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. This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin. Already stated that, sample are non-production stuff that should *never* be built into binary delivery package. So no matter whether you enable/disable the sample plugin, it should be left out from binary delivery package.
If the command itself is only for build time, the command itself should not be shipped in binary delivery package.
I think it's obvious that none of the build scripts get packaged, so no matter what magic we do in them, the end-user never sees them.
For the content of binary delivery, it is determined by the packaging/distribution strategy, it has nothing to do with whether a plugin is enabled or disabled. A by default disabled plugin can also be shipped in final delivery
The concept to connect "enable/disable plugin" to "the content of build output" itself does not make any sense. Sample will only be of significance at development time and at run-time.
That's exactly why we can add a built time switch to toggle to sample plugin. If the sample plugin was packaged, we would never have a chance to do this. This build time switch is only for development time convenience. It's not invasive and does not shipped in the build result. It's ok we don't have it if you think it's too "magical". We can just make it disabled.
As regard to runtime configuration, manually changing "enabled = False/True" is enough. For now the only valid use case to enable and disable a plugin is that a plugin developer experimenting some new things on the "sample", and this case is rare. I think there's little value to add new command for a rare case. Notice that even the third-party developers do not need to toggle the sample plugin, and only when we want to extend the plugin framework itself, we have to enable the sample and test it. So this use case is really rare. Again, for runtime,
For development, it is ok to modify some config file because it just follow *my original design* that "*plugin should have a way to disable itself*".
And this patch does not change this design, it just adds a build time switch for the developers in development time.
For production operations, it is *not* ok for admin to modify the config file, a command is required at runtime to enable/disable plugin which is shipped in binary delivery package.
It's actually OK. For now Kimchi is still a small project with a lot of core requirement to fufill, so the current "just-work" plugin framework is acceptable. Fully functional plugins management can be considered only when the project itself is mature. Or if you think it's important, bring up a new thread and your RFC patches and discuss, and make it go through a full and formal development progress. But for solving #Issue 342, this patch is practical and acceptable.
In all, "--enable-sample" is an acceptable solution for the developer to toggle the sample plugin occasionally in the developing environment. It's also acceptable that we don't have any switches or options at all, and the "enabled = False" is the default in "sample.conf". Whenever the developer wants to experiment something, just manually edit it and restart Kimchi back-end server. Stated above,
For development, no additional command is needed at all, if I understand you correctly, there is already a way for plugin to disable itself. For the "--enable-sample" command itself, there is no reason to design a command specially for a sample and it need additional handling to leave it out from binary delivery.
It does not need additional handling. I don't see any additional work is needed to make it out from the final package. The patch neither changes the RPM spec or DEB rules, noticing that the RPM and DEB's build time switches are defined inside RPM spec and DEB rules. The only thing it does is toggle the default availability at build time and this default availability only affects when you start Kimchi server from source code directory in the development time.
Anything that is not target for production(for example, the sample) should *not* be built into the final binary delivery package. True, the sample plugin didn't, doesn't and won't be in the binary package. The switch in this patch is just to toggle its availability when developer runs Kimchi from source code. I am a bit confused here.
Here, seems like here you mean that the 'switch' is for run-time.
At the beginning, you said below, the 'switch' is for build time.
/This patch is all about build time configuration. "--enable-plugin-X" is a switch given to the build scripts. The switch sets the default availability of a plugin./
No matter whether you mean run-time or build-time, stated above, sample should *never* be built into binary package, a *switch* is not needed at all.
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. If the user does not want a plugin, he can just uninstalls it. For functionality completeness, a plugin can be installed/uninstalled/enabled/disabled like firebug 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.
-- Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
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:
From: ShaoHe Feng <shaohef@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
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote: 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
on 2014/05/21 14:48, Yu Xin Huo wrote:
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.
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.
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.
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.
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'd prefer --enable-sample to manual file coping.
I would like to listen to whole Team's voice.
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.
On 5/19/2014 5:31 PM, Yu Xin Huo wrote:
From: ShaoHe Feng <shaohef@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
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote: 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
-- Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
On 5/21/2014 5:43 PM, Zhou Zheng Sheng wrote:
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. Kimchi does not provide any plugins other than "sample". All plugins are
on 2014/05/21 14:48, Yu Xin Huo wrote: 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. Stated in another reply, nothing related to build time.
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. 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. Stated in another reply, nothing related to build time. All about run-time.
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'd prefer --enable-sample to manual file coping. I have stated many times, "--enable-sample" is not good or bad, it is *wrong*. I would like to listen to whole Team's voice. 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. For production, there is no such a problem about the sample as it will not be packaged in the binary delivery.
From this discussion, we see a real requirement to enable/disable a deployed plugin. For development time, it make sense to leverage "sample.conf" which looks like some typical technical person's style. 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.
On 5/19/2014 5:31 PM, Yu Xin Huo wrote:
From: ShaoHe Feng <shaohef@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
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote: 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com> please use this command to generate the translation files for plugins/sample $ make -C plugins/sample/po/ update-po Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- configure.ac | 1 + plugins/sample/Makefile.am | 7 +++++++ plugins/sample/config.status | 1 + plugins/sample/po/LINGUAS | 1 + plugins/sample/po/Makefile.in.in | 1 + plugins/sample/po/Makevars | 1 + plugins/sample/po/POTFILES.in | 2 ++ plugins/sample/po/en_US.po | 21 +++++++++++++++++++++ plugins/sample/po/gen-pot | 1 + plugins/sample/po/pt_BR.po | 24 ++++++++++++++++++++++++ plugins/sample/po/zh_CN.po | 24 ++++++++++++++++++++++++ 11 files changed, 84 insertions(+) create mode 120000 plugins/sample/config.status create mode 120000 plugins/sample/po/LINGUAS create mode 120000 plugins/sample/po/Makefile.in.in create mode 120000 plugins/sample/po/Makevars create mode 100644 plugins/sample/po/POTFILES.in create mode 100644 plugins/sample/po/en_US.po create mode 120000 plugins/sample/po/gen-pot create mode 100644 plugins/sample/po/pt_BR.po create mode 100644 plugins/sample/po/zh_CN.po diff --git a/configure.ac b/configure.ac index ab1b302..55dd3a8 100644 --- a/configure.ac +++ b/configure.ac @@ -72,6 +72,7 @@ AC_CONFIG_FILES([ src/kimchi/model/Makefile plugins/Makefile plugins/sample/Makefile + plugins/sample/po/Makefile.in plugins/sample/ui/Makefile plugins/sample/ui/config/Makefile ui/Makefile diff --git a/plugins/sample/Makefile.am b/plugins/sample/Makefile.am index b0beb32..f438e3a 100644 --- a/plugins/sample/Makefile.am +++ b/plugins/sample/Makefile.am @@ -36,3 +36,10 @@ sample.conf: sample.conf.in Makefile BUILT_SOURCES = sample.conf CLEANFILES = sample.conf + +all-local: + while read L && test -n "$$L"; do \ + dir=mo/$$L/LC_MESSAGES ; \ + $(MKDIR_P) $$dir ; \ + ln -sf ../../../po/$$L.gmo $$dir/kimchi.mo ; \ + done < po/LINGUAS diff --git a/plugins/sample/config.status b/plugins/sample/config.status new file mode 120000 index 0000000..6cd6b4f --- /dev/null +++ b/plugins/sample/config.status @@ -0,0 +1 @@ +../../config.status \ No newline at end of file diff --git a/plugins/sample/po/LINGUAS b/plugins/sample/po/LINGUAS new file mode 120000 index 0000000..4fb83a5 --- /dev/null +++ b/plugins/sample/po/LINGUAS @@ -0,0 +1 @@ +../../../po/LINGUAS \ No newline at end of file diff --git a/plugins/sample/po/Makefile.in.in b/plugins/sample/po/Makefile.in.in new file mode 120000 index 0000000..44028c0 --- /dev/null +++ b/plugins/sample/po/Makefile.in.in @@ -0,0 +1 @@ +../../../po/Makefile.in.in \ No newline at end of file diff --git a/plugins/sample/po/Makevars b/plugins/sample/po/Makevars new file mode 120000 index 0000000..3b6b02f --- /dev/null +++ b/plugins/sample/po/Makevars @@ -0,0 +1 @@ +../../../po/Makevars \ No newline at end of file diff --git a/plugins/sample/po/POTFILES.in b/plugins/sample/po/POTFILES.in new file mode 100644 index 0000000..f1b069f --- /dev/null +++ b/plugins/sample/po/POTFILES.in @@ -0,0 +1,2 @@ +# List of source files which contain translatable strings. +ui/pages/*.tmpl diff --git a/plugins/sample/po/en_US.po b/plugins/sample/po/en_US.po new file mode 100644 index 0000000..1889845 --- /dev/null +++ b/plugins/sample/po/en_US.po @@ -0,0 +1,21 @@ +# English translations for kimchi package. +# Copyright (C) 2014 THE kimchi'S COPYRIGHT HOLDER +# This file is distributed under the same license as the kimchi package. +# shhfeng <shaohef@linux.vnet.ibm.com>, 2014. +# +msgid "" +msgstr "" +"Project-Id-Version: kimchi 1.2.0\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2014-05-17 02:13+0800\n" +"PO-Revision-Date: 2014-05-17 02:08+0800\n" +"Last-Translator: shhfeng <shaohef@linux.vnet.ibm.com>\n" +"Language-Team: English\n" +"Language: en_US\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=ASCII\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: pygettext.py 1.5\n" + +msgid "SampleTab" +msgstr "SampleTab" diff --git a/plugins/sample/po/gen-pot b/plugins/sample/po/gen-pot new file mode 120000 index 0000000..b449d56 --- /dev/null +++ b/plugins/sample/po/gen-pot @@ -0,0 +1 @@ +../../../po/gen-pot \ No newline at end of file diff --git a/plugins/sample/po/pt_BR.po b/plugins/sample/po/pt_BR.po new file mode 100644 index 0000000..e36e99a --- /dev/null +++ b/plugins/sample/po/pt_BR.po @@ -0,0 +1,24 @@ +# Portuguese translations for kimchi package +# Copyright (C) 2014 THE kimchi'S COPYRIGHT HOLDER +# This file is distributed under the same license as the kimchi package. +# shhfeng <shaohef@linux.vnet.ibm.com>, 2014. +# +msgid "" +msgstr "" +"Project-Id-Version: kimchi 1.2.0\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2014-05-17 02:13+0800\n" +"PO-Revision-Date: 2014-05-17 02:09+0800\n" +"Last-Translator: Crístian Viana <vianac@linux.vnet.ibm.com>\n" +"Language-Team: Aline Manera <alinefm@br.ibm.com>\n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: pygettext.py 1.5\n" +"X-Poedit-Country: Brazil\n" +"X-Poedit-Language: Portuguese\n" +"X-Poedit-SourceCharset: utf-8\n" + +msgid "SampleTab" +msgstr "Tab Amostra" diff --git a/plugins/sample/po/zh_CN.po b/plugins/sample/po/zh_CN.po new file mode 100644 index 0000000..bba53c3 --- /dev/null +++ b/plugins/sample/po/zh_CN.po @@ -0,0 +1,24 @@ +# Chinese translations for kimchi package +# Copyright (C) 2014 THE kimchi'S COPYRIGHT HOLDER +# This file is distributed under the same license as the kimchi package. +# shhfeng <shaohef@linux.vnet.ibm.com>, 2014. +# +msgid "" +msgstr "" +"Project-Id-Version: kimchi 1.2.0\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2014-05-17 02:13+0800\n" +"PO-Revision-Date: 2014-05-17 02:10+0800\n" +"Last-Translator: shhfeng <shaohef@linux.vnet.ibm.com>\n" +"Language-Team: Chinese (simplified)\n" +"Language: zh_CN\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: pygettext.py 1.5\n" +"X-Poedit-Country: CHINA\n" +"X-Poedit-Language: Chinese\n" +"X-Poedit-SourceCharset: utf-8\n" + +msgid "SampleTab" +msgstr "示例标签" -- 1.9.0
On 05/17/2014 03:30 AM, shaohef@linux.vnet.ibm.com wrote:
+ +msgid "SampleTab" +msgstr "Tab Amostra" which is right? Tab amostra de Exemplo Tab Tab da amostra
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
I think "Tab de exemplo" looks better. On 16-05-2014 22:48, Sheldon wrote:
On 05/17/2014 03:30 AM, shaohef@linux.vnet.ibm.com wrote:
+ +msgid "SampleTab" +msgstr "Tab Amostra" which is right? Tab amostra de Exemplo Tab Tab da amostra
On 5/17/2014 3:30 AM, shaohef@linux.vnet.ibm.com wrote:
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com>
please use this command to generate the translation files for plugins/sample $ make -C plugins/sample/po/ update-po Please clarify whether this command is a sample to generate po files for a certain plugin or a command to specially generate po files for that sample plugin.
Signed-off-by: ShaoHe Feng <shaohef@linux.vnet.ibm.com> --- configure.ac | 1 + plugins/sample/Makefile.am | 7 +++++++ plugins/sample/config.status | 1 + plugins/sample/po/LINGUAS | 1 + plugins/sample/po/Makefile.in.in | 1 + plugins/sample/po/Makevars | 1 + plugins/sample/po/POTFILES.in | 2 ++ plugins/sample/po/en_US.po | 21 +++++++++++++++++++++ plugins/sample/po/gen-pot | 1 + plugins/sample/po/pt_BR.po | 24 ++++++++++++++++++++++++ plugins/sample/po/zh_CN.po | 24 ++++++++++++++++++++++++ 11 files changed, 84 insertions(+) create mode 120000 plugins/sample/config.status create mode 120000 plugins/sample/po/LINGUAS create mode 120000 plugins/sample/po/Makefile.in.in create mode 120000 plugins/sample/po/Makevars create mode 100644 plugins/sample/po/POTFILES.in create mode 100644 plugins/sample/po/en_US.po create mode 120000 plugins/sample/po/gen-pot create mode 100644 plugins/sample/po/pt_BR.po create mode 100644 plugins/sample/po/zh_CN.po
diff --git a/configure.ac b/configure.ac index ab1b302..55dd3a8 100644 --- a/configure.ac +++ b/configure.ac @@ -72,6 +72,7 @@ AC_CONFIG_FILES([ src/kimchi/model/Makefile plugins/Makefile plugins/sample/Makefile + plugins/sample/po/Makefile.in plugins/sample/ui/Makefile plugins/sample/ui/config/Makefile ui/Makefile diff --git a/plugins/sample/Makefile.am b/plugins/sample/Makefile.am index b0beb32..f438e3a 100644 --- a/plugins/sample/Makefile.am +++ b/plugins/sample/Makefile.am @@ -36,3 +36,10 @@ sample.conf: sample.conf.in Makefile
BUILT_SOURCES = sample.conf CLEANFILES = sample.conf + +all-local: + while read L && test -n "$$L"; do \ + dir=mo/$$L/LC_MESSAGES ; \ + $(MKDIR_P) $$dir ; \ + ln -sf ../../../po/$$L.gmo $$dir/kimchi.mo ; \ + done < po/LINGUAS diff --git a/plugins/sample/config.status b/plugins/sample/config.status new file mode 120000 index 0000000..6cd6b4f --- /dev/null +++ b/plugins/sample/config.status @@ -0,0 +1 @@ +../../config.status \ No newline at end of file diff --git a/plugins/sample/po/LINGUAS b/plugins/sample/po/LINGUAS new file mode 120000 index 0000000..4fb83a5 --- /dev/null +++ b/plugins/sample/po/LINGUAS @@ -0,0 +1 @@ +../../../po/LINGUAS \ No newline at end of file diff --git a/plugins/sample/po/Makefile.in.in b/plugins/sample/po/Makefile.in.in new file mode 120000 index 0000000..44028c0 --- /dev/null +++ b/plugins/sample/po/Makefile.in.in @@ -0,0 +1 @@ +../../../po/Makefile.in.in \ No newline at end of file diff --git a/plugins/sample/po/Makevars b/plugins/sample/po/Makevars new file mode 120000 index 0000000..3b6b02f --- /dev/null +++ b/plugins/sample/po/Makevars @@ -0,0 +1 @@ +../../../po/Makevars \ No newline at end of file diff --git a/plugins/sample/po/POTFILES.in b/plugins/sample/po/POTFILES.in new file mode 100644 index 0000000..f1b069f --- /dev/null +++ b/plugins/sample/po/POTFILES.in @@ -0,0 +1,2 @@ +# List of source files which contain translatable strings. +ui/pages/*.tmpl diff --git a/plugins/sample/po/en_US.po b/plugins/sample/po/en_US.po new file mode 100644 index 0000000..1889845 --- /dev/null +++ b/plugins/sample/po/en_US.po @@ -0,0 +1,21 @@ +# English translations for kimchi package. +# Copyright (C) 2014 THE kimchi'S COPYRIGHT HOLDER +# This file is distributed under the same license as the kimchi package. +# shhfeng <shaohef@linux.vnet.ibm.com>, 2014. +# +msgid "" +msgstr "" +"Project-Id-Version: kimchi 1.2.0\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2014-05-17 02:13+0800\n" +"PO-Revision-Date: 2014-05-17 02:08+0800\n" +"Last-Translator: shhfeng <shaohef@linux.vnet.ibm.com>\n" +"Language-Team: English\n" +"Language: en_US\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=ASCII\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: pygettext.py 1.5\n" + +msgid "SampleTab" +msgstr "SampleTab" diff --git a/plugins/sample/po/gen-pot b/plugins/sample/po/gen-pot new file mode 120000 index 0000000..b449d56 --- /dev/null +++ b/plugins/sample/po/gen-pot @@ -0,0 +1 @@ +../../../po/gen-pot \ No newline at end of file diff --git a/plugins/sample/po/pt_BR.po b/plugins/sample/po/pt_BR.po new file mode 100644 index 0000000..e36e99a --- /dev/null +++ b/plugins/sample/po/pt_BR.po @@ -0,0 +1,24 @@ +# Portuguese translations for kimchi package +# Copyright (C) 2014 THE kimchi'S COPYRIGHT HOLDER +# This file is distributed under the same license as the kimchi package. +# shhfeng <shaohef@linux.vnet.ibm.com>, 2014. +# +msgid "" +msgstr "" +"Project-Id-Version: kimchi 1.2.0\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2014-05-17 02:13+0800\n" +"PO-Revision-Date: 2014-05-17 02:09+0800\n" +"Last-Translator: Crístian Viana <vianac@linux.vnet.ibm.com>\n" +"Language-Team: Aline Manera <alinefm@br.ibm.com>\n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: pygettext.py 1.5\n" +"X-Poedit-Country: Brazil\n" +"X-Poedit-Language: Portuguese\n" +"X-Poedit-SourceCharset: utf-8\n" + +msgid "SampleTab" +msgstr "Tab Amostra" diff --git a/plugins/sample/po/zh_CN.po b/plugins/sample/po/zh_CN.po new file mode 100644 index 0000000..bba53c3 --- /dev/null +++ b/plugins/sample/po/zh_CN.po @@ -0,0 +1,24 @@ +# Chinese translations for kimchi package +# Copyright (C) 2014 THE kimchi'S COPYRIGHT HOLDER +# This file is distributed under the same license as the kimchi package. +# shhfeng <shaohef@linux.vnet.ibm.com>, 2014. +# +msgid "" +msgstr "" +"Project-Id-Version: kimchi 1.2.0\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2014-05-17 02:13+0800\n" +"PO-Revision-Date: 2014-05-17 02:10+0800\n" +"Last-Translator: shhfeng <shaohef@linux.vnet.ibm.com>\n" +"Language-Team: Chinese (simplified)\n" +"Language: zh_CN\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: pygettext.py 1.5\n" +"X-Poedit-Country: CHINA\n" +"X-Poedit-Language: Chinese\n" +"X-Poedit-SourceCharset: utf-8\n" + +msgid "SampleTab" +msgstr "示例标签"
participants (5)
-
Crístian Viana -
shaohef＠linux.vnet.ibm.com -
Sheldon
-
Yu Xin Huo -
Zhou Zheng Sheng