First, a short detour into how plugins in abrt2 are planned to work.
Requests to do something with a crash dump originate from clients (cli, gui, web...).
These requests can be sent over a Unix (or TCP) socket connection to abrtd; or they can be sent over dbus to (autostarted) abrt-dbus.
In either case, abrtd or abrt-dbus starts abrt-server process for each client and then passes commands from the client to the corresponding abrt-server, and passes responses back.
This makes abrtd and abrt-dbus simpler and allows for parallelism (IOW: fixes current design bug where reporting is serialized).
abrt-server reads configuration and starts children (sequentially) to process the crash dump. These children are plugins.
abrt-server and its children talk to client over stdin/out (which is then piped back and forth by abrtd or abrt-dbus).
This email is meant to kickstart the discussion what level of interactivity we want to implement in plugin<->client propocol.
In abrt1, communication goes approximately this way:
client plugin ====== ========= Report crashdump_dir reporter user_conf_data ----> <------ M: message "Download 45/234: foo.rpm" <------ W: warning msg <------ E: error (the operation failed), "message" <------ R: successful completion, "message"
This is not adequate. Say, * Bz plugin might want to prompt for additional data (bz login/password), * or might need to tell client that it is capable of attaching files and therefore client needs to prompt user to choose which files in crash dump dir need to be attached. * (more cases we want to cover?)
We can extend protocol by adding a "Question" request: <------ Q: Textual prompt ("Bz username:") or by introducing error codes: <------ E: 666 Username required or ???
And/or we might add more commands with which client can interrogate plugins about their capabilities: New cmd: Query_capabilities CDUMPDIR reporter ----> <----- I can attach files <----- I need USERNAME, PASSWORD, CLIENT_ID
In abrt1, communication goes approximately this way:
client plugin ====== ========= Report crashdump_dir reporter user_conf_data ----> <------ M: message "Download 45/234: foo.rpm" <------ W: warning msg <------ E: error (the operation failed), "message" <------ R: successful completion, "message"
This is not adequate. Say,
- Bz plugin might want to prompt for additional data (bz
login/password),
- or might need to tell client that it is capable of attaching files
and therefore client needs to prompt user to choose which files in crash dump dir need to be attached.
- (more cases we want to cover?)
We can extend protocol by adding a "Question" request: <------ Q: Textual prompt ("Bz username:") or by introducing error codes: <------ E: 666 Username required or
This is suitable for the CLI, where every question from the plugin is presented as one line question in the CLI:
Please enter the BZ login: <enter> Please enter the password: <enter> Do you want to attach files? <enter>
This is actually how it works in the CLI now. But this is not good for the GUI. Asking user for every piece of information in a separated dialog is not a good idea and we'll be cursed by users... So gui has to group these questions/suggestions. So the first option is:
And/or we might add more commands with which client can interrogate plugins about their capabilities: New cmd: Query_capabilities CDUMPDIR reporter ----> <----- I can attach files <----- I need USERNAME, PASSWORD, CLIENT_ID
if we can ask:
client reporter Query_missing_info CDUMPDIR reporter ----> <----- I'm missing [PASSWORD, LOGIN, URL]
then we can ask for all of the missing info at once and don't bother user with 5 popups...
But there is more...:
Every plugin can have a different set of capabilities like:
1. BZ can check if the bug is reported before it reports it, but e.g. kerneloops can't 2. BZ can provide the test() method to test the login/pass before trying to report...
Trying to build a UI for this just from a textual description taken from querying the plugin would be hell, so my proposal here is to implement a real plugin into GUI (I don't think it's needed for the cli..) which won't be just the glade files as it is now, but the python scripts which will provide:
The config dialog Can add buttons to the UI (like "search the bz")
the advantage of this is we can implement a lot of logic on the plugin side (like check if the pass/login/url/whatever seems to be fine) and actually we can store the capabilities in it so we won't have to ask the plugin (but the query_missing still stays..) So the only problem here is to define the API for the plugins and decide what and how the plugins can change the GUI: where to put the "search" button, where to display the attachments...
Jirka
crash-catcher@lists.fedorahosted.org
-
Denys Vlasenko -
Jiri Moskovcak