File bugs via XML-RPC when possible

If the server supports XML-RPC (3.0 or newer), then filing via
xmlrpc.cgi has advantages:

 - We get a string error message instead of an HTML page
 - We can not specify priority/severity and let the server
   default it; this is important since there aren't standard
   priorities.

So, we try to first file via xmlrpc.cgi's Bug.create method and
if we get a 404, fall back to the old method of a form post.

The configuration for a couple of fields is changed to use the human
readable field names from Bug.create rather than the database-field
names of post_bug.cgi.

 default-bug-severity => default-severity
 default-rep-platform => default-platform

1 files changed, 3 insertions, 11 deletions

diff --git a/TODO b/TODO
index 27197b1..5629e56 100644
--- a/TODO
+++ b/TODO
@@ -24,23 +24,15 @@ Automatically guess obvious obsoletes
  matches the Subject of the attachment, start the Obsoletes line
  uncommented?
 
-Use XML-RPC when available.
-
-  Maybe use python-bugzilla: http://fedorahosted.org/python-bugzilla/
-
-  Not sure there are a lot of advantages to this; one thing that it
-  might be possible to do with this is allow the user to specify only
-  the product and get an interactive list of components. Also, better
-  error handling.
-
 Handle redirects:
 
   Should follow redirects, both to different URLs and http => https
 
 Better display of errors
 
-  Currently specifying a non-existent product/component just dumps
-  out raw HTML for the reply. Etc.
+  The switch to XML-RPC greatly improves errors when filing a new bug,
+  but other problems (e.g., having stale login cookies when making an
+  attachment) still just dump HTML pages error pages to the console.
 
 More general patch application