On 07/08/2010 11:06 AM, Jiri Moskovcak wrote:
Just a quick dump from yestarday:
As Karel said, we need a better way to communicate with the "plugins"
and let users to override some settings ad-hoc, show the settings in
UIs, etc...
So what if we remove abrt-handle-crashdump and let abrt-server to handle
all of it's work:
1. parse the config
2. send the actual configuration to UI if necessary
3. run the action(s)
(we can even keep acbrt-handle-crashdump, but in this case all it's work
would be to run action with parameters given by abrt-server)
- so the abrt-server can serve the calls like {Get,Set}PluginSettings
Yes, Get/SetPluginSettings on abrt-server level seems to be useful.
How would moving the stuff to abrt-server help you to handle custom GUI
for plugin settings and custom wizard steps?
My second proposal is for the config file:
1. store it in /etc/abrt/actions.d/
2. I would vote for some more readable format like XML:
for example:
<action>
<stage>uploaded</stage>
<command>abrt-action-generate-backtrace</command>
<option mandatory="yes">option1</option>
<option default="foo">option2</option
or to avoid attrs
<option>
<name>option3</name>
<default>foobar</default>
<mandatory>yes</mandatory>
</option>
</action>
extending the xml config file should be less painful then adding new
column in the previous table like proposal.
Looking forward for you comments :)
Jirka
> ===============================================================
>
> For reference, abrt1 plugins are:
>
> Bugzilla.cpp
> CCpp.cpp
> FileTransfer.cpp
> Kerneloops.cpp
> KerneloopsScanner.cpp
> Logger.cpp
> Mailx.cpp
> Python.cpp
> RHTSupport.cpp
> RunApp.cpp
> SOSreport.cpp
> ReportUploader.cpp
>