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
--
vda