I'd like to enhance Roundup's separation between the user interface and
the tracker instance behavior. In particular, while detectors are fired
from within the hyperdb, actions right now are only available to the CGI
interface.

I'd like to suggest a series of enhancements that allows users to
provide actions that are callable via different interfaces (such as XMLRPC).

As a first step, here is a patch that allows cgi.client to multiplex
requests to an XMLRPC request handler, if the content-type of request is
text/xml.

A couple of comments on this patch:

1) I had to slightly refactor bits to break out of a dependency loop. (I
moved the 'UsageError' definition from admin to exceptions, so the
xmlrpc module could use it without becoming dependent on cgi itself.)

2) I now realize how badly I designed xmlrpc.RoundupServer. In
particular, as it does its own authentication, I couldn't use it from
within cgi.client. In this patch I added a new 'RoundupServer2' that
corrects that. I wonder how great the chances are that the original
RoundupServer is used directly by anybody, and thus, whether we could
break backwards-compatibility by just replacing it by the new one.)

While I have working prototype code of a new roundup.actions module,
callable both directly via XMLRPC, as well as bia a bridge in
roundup.cgi.actions, I'd rather keep that as a separate patch.

How does this look ?

I just checked in rev:4171. With that, cgi.client dispatches XMLRPC
requests, too. (XMLRPC requests are distinguished from ordinary CGI
requests by Content-Type being 'text/xml'.)

Now on to generalized actions...

I have added a roundup.actions module containing built-in actions
callable via XMLRPC (and soon, with some bridging), via CGI.

I now wonder how to expose this to users so they can provide their own
actions. Right now they have instance.registerAction(). But as we now
have to types of actions, I need a discriminator.

If we can be certain that all actions derive either from
roundup.cgi.actions.Action or roundup.actions.Action, I can use a simple
type check. However, I'm not sure that this is a reasonable assumption
to make. Richard, what do you think ?

I have just added support for actions to the XMLRPC interface, and added 
an easy mechanism for users to write actions that are executable through 
both, XMLRPC as well as CGI:
(http://svn.roundup-tracker.org/viewvc/roundup?view=rev&revision=4175)

roundup.cgi.actions provides a new class 'Bridge', that translates all 
form variables into a dictionary, which then gets passed as (single) 
argument to handle(). Thus, the following user action will do the 
obvious thing::

   from roundup.cgi.actions import Bridge

   class Echo(Bridge):

       def handle(self, args):

           if self.cgi:
               self.client.ok_message.append(str(args))
           else:
               return args

   def init(instance):

       instance.registerAction("echo", Echo)

Thus, in order for an action class to be executable like this, it needs:

* derive from roundup.cgi.actions.Bridge
* use a signature like the above, i.e. a single argument being a dictionary.

Users can provide XMLRPC-only actions by simply deriving from 
roundup.cgi.actions.Action.
In all other cases, registerAction() will register it as a conventional 
(cgi) action.

I would appreciate any feedback on this. Is this a useful interface ? 
Are there things that need to be modified or added (or removed !) for it 
to be more broadly useful ?

Also note that as of now, the XMLRPC interface is accessible through the 
web frontends (roundup.cgi, apache.py, and roundup-server), as well as 
through the standalone roundup-xmlrpc-server. This should make remote 
access (administration, in particular) easier.

Thanks,
		Stefan