classification
Title: Add XML-RPC Fault Interoperability to XMLRPC libraries
Type: enhancement Stage: test needed
Components: Library (Lib) Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: jaginsberg, loewis
Priority: normal Keywords: easy, patch

Created on 2005-11-18 16:22 by jaginsberg, last changed 2009-06-20 16:55 by loewis. This issue is now closed.

Files
File name Uploaded Description Edit
xmlrpc-fault-interop.20051118.patch jaginsberg, 2005-11-18 16:22 Ze patch, boss! Ze patch!
Messages (3)
msg49075 - (view) Author: Joshua Ginsberg (jaginsberg) Date: 2005-11-18 16:22
Patched against 2.4.2

SimpleXMLRPCServer.py

* Added SimpleXMLRPCDispatcher.register_capability() to
manage results for system.getCapabilities() RPC call.

* Added
SimpleXMLRPCDispatcher.register_fault_interop_spec() to
make fault codes compliant with the specification

* Abstracted fault code constants.

xmlrpclib.py

* Added more detailed exception raising for failures in
XML-RPC request parsing.

msg49076 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-11-19 10:23
The patch looks good, however, I have a few questions:

- what is the purpose of abstracting fault code constants? For interoperability, I think they should always have the specified values. Furthermore, if register_fault_interop_spec isn't called, it will give 1 as the fault code if some of these faults occurs, which is bad.

- why is system.getCapabilities registered in register_fault_interop_spec? That sounds backwards: there should be a register_get_capabilities function, or better yet, this should get registered with register_introspection_functions.

- if you agree to these changes so far, I think register_fault_interop_spec should go away, or invoked by default. What is the purpose of making it optional (especially since raising the faults is not optional)?

- Please provide documentation changes (i.e. a patch to Doc/lib/libsimplexmlrpc.tex, and Doc/lib/libxmlrpc.tex)

- I think ParseError should support "nested" exceptions: the original exception should be included into the ParseError object, in case people want to know the details of the underlying parser error.
msg89544 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-06-20 16:55
Rejecting the patch because of lack of responsiveness.
History
Date User Action Args
2009-06-20 16:55:32loewissetstatus: open -> closed
resolution: rejected
messages: + msg89544
2009-04-22 14:36:08ajaksu2setkeywords: + easy
2009-03-20 23:32:27ajaksu2setstage: test needed
type: enhancement
versions: + Python 3.1, Python 2.7, - Python 2.4
2005-11-18 16:22:12jaginsbergcreate