Instead of Batchmgr being an interface:
- currently the existing implementation of BatchMgr, 'XmlRpcBatchMgr', has nothing to do with XmlRpc besides that is uses XmlRpcBatchMgrProxy, which is really what does all the XmlRpc communications. XmlRpcBatchMgr currently does everything which all BatchMgr's need to perform (i.e. updating repo, monitor, etc), where as, i argue, XmlRpcBatchMgrProxy actually performs the tasks which one would want to be customizable.
- my purposed change: Create an interface, 'BatchMgrProxy', and make XmlRpcBatchMgrProxy extend it, while also making it the default BatchMgrProxy, while adding to ResourceNode the ability to store a BatchMgrProxy, which is used to communicate with the batchstub at that ResourceNode uri. This would allow a developer to added additional Proxy-Monitoring to a BatchMgrProxy which may be needed on a per node bases (i.e. a batch stub running on a EC2 node needs additional Proxy functionality over the existing functionality needed to submit to a batch stub running locally). XmlRpcBatchMgr would become BatchMgr, and would get added support for handling node based Proxies.