On 07/08/2010 02:34 PM, Karel Klic wrote:
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?
The plugin options can be described in the xml config file (it would be
quite similar to what we have now, except it won't be a glade file ...),
but the custom wizard step needs some more thinking to make it right...
> 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
>>
>