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