Hi, I got an idea about the reporters which I'd like to share and maybe implement if we agree on it. So here it comes:
As you know our reporters has pretty limited options how to communicate with users - they can only return some text to display. But what if the plugin would like to ask user to do some action - like use other plugin or run some command? So we can change the type of the return value to something better like:
struct report_result { type: {MESSAGE,ACTION,PLUGIN} content: - depends on type, but its always a string: -> for MESSAGE it would be the message -> for ACTION it would be a command -> for PLUGIN it would be the plugin name to use which might be then represented as a button in gui }
or maybe a list of these structs, so we can return a message and action or more actions ...
Ideas?
J.
On Wed, 2010-03-17 at 14:44 +0100, Jiri Moskovcak wrote:
I got an idea about the reporters which I'd like to share and maybe implement if we agree on it. So here it comes:
As you know our reporters has pretty limited options how to communicate with users - they can only return some text to display. But what if the plugin would like to ask user to do some action - like use other plugin or run some command? So we can change the type of the return value to something better like:
struct report_result { type: {MESSAGE,ACTION,PLUGIN} content: - depends on type, but its always a string: -> for MESSAGE it would be the message -> for ACTION it would be a command -> for PLUGIN it would be the plugin name to use which might be then represented as a button in gui }
or maybe a list of these structs, so we can return a message and action or more actions ...
Ideas?
Is there a need for such functionality right now?
Not just "it would be cool if plugin A could instruct gui to run plugin B", but "we need to do this and this and current design does not allow it"
If yes, please describe the situation.
On 03/18/2010 03:54 PM, Denys Vlasenko wrote:
On Wed, 2010-03-17 at 14:44 +0100, Jiri Moskovcak wrote:
I got an idea about the reporters which I'd like to share and maybe implement if we agree on it. So here it comes:
As you know our reporters has pretty limited options how to communicate with users - they can only return some text to display. But what if the plugin would like to ask user to do some action - like use other plugin or run some command? So we can change the type of the return value to something better like:
struct report_result { type: {MESSAGE,ACTION,PLUGIN} content: - depends on type, but its always a string: -> for MESSAGE it would be the message -> for ACTION it would be a command -> for PLUGIN it would be the plugin name to use which might be then represented as a button in gui }
or maybe a list of these structs, so we can return a message and action or more actions ...
Ideas?
Is there a need for such functionality right now?
Not just "it would be cool if plugin A could instruct gui to run plugin B", but "we need to do this and this and current design does not allow it"
If yes, please describe the situation.
The workflow that comes to me mind is .. Plugin A has an ability to verify bug against list of known and solved issue. Something like FAQ or knowledgebase. If the solution is found there, another plugin should either do some fixes on the system according to that FAQ or offer sending that problem to support/bugzilla. Eg. I see this as a support for kind of a Wizard type of reporting, where user can be taken thru several steps before finally submitting a bug.
Am I right Jiri?
Radek
On 03/19/2010 01:01 PM, Radek Vokál wrote:
On 03/18/2010 03:54 PM, Denys Vlasenko wrote:
On Wed, 2010-03-17 at 14:44 +0100, Jiri Moskovcak wrote:
I got an idea about the reporters which I'd like to share and maybe implement if we agree on it. So here it comes:
As you know our reporters has pretty limited options how to communicate with users - they can only return some text to display. But what if the plugin would like to ask user to do some action - like use other plugin or run some command? So we can change the type of the return value to something better like:
struct report_result { type: {MESSAGE,ACTION,PLUGIN} content:
- depends on type, but its always a string:
-> for MESSAGE it would be the message -> for ACTION it would be a command -> for PLUGIN it would be the plugin name to use which might be then represented as a button in gui }
or maybe a list of these structs, so we can return a message and action or more actions ...
Ideas?
Is there a need for such functionality right now?
Not just "it would be cool if plugin A could instruct gui to run plugin B", but "we need to do this and this and current design does not allow it"
If yes, please describe the situation.
The workflow that comes to me mind is .. Plugin A has an ability to verify bug against list of known and solved issue. Something like FAQ or knowledgebase. If the solution is found there, another plugin should either do some fixes on the system according to that FAQ or offer sending that problem to support/bugzilla. Eg. I see this as a support for kind of a Wizard type of reporting, where user can be taken thru several steps before finally submitting a bug.
Am I right Jiri?
Radek
Exactly chaining the plugins might be the way how to guide user to find the solution before he creates the ticket and how to implement the whole logic into plugins so the GUI/CLI just need to know how to present MESSAGE and ACTION. Please take this as a discussion starter, I'm not saying that this is the design we have to implement, there might be some other ways, how to achieve this.
J.
crash-catcher@lists.fedorahosted.org