convention to represent the exit status and actual result in XMLRPC

Question

in the C world, a function can return error code to represent the exit status, and use INOUT/OUT parameter to carry the actual fruit of the process. when it comes to xmlrpc, no INOUT/OUT parameter, is there any best practice/conventions to represent the exit status and actual result?

the context is i am trying to write an agent/daemon (python SimpleXMLRPCServer) running on the Server, and want to design the "protocol" to interact with it.

any advice is appreciated.

EDIT : per S.Lott's comment, make the problem more clear.

• it is more about os convention rather than C convention. I agree with that.

• the job of the agent is more or less run some cmd on the server, inherently with an exit code/result idiom

.

Answer 1

One simple way to implement this in Python is with a tuple. Have your function return a tuple of: (status, result) where the status can be numeric or a string, and the result can be any Python data structure you fancy.

Here's an example, adapted from the module documentation. Server code:

from SimpleXMLRPCServer import SimpleXMLRPCServer
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler

# Restrict to a particular path.
class RequestHandler(SimpleXMLRPCRequestHandler):
    rpc_paths = ('/RPC2',)

# Create server
server = SimpleXMLRPCServer(("localhost", 8000),
                            requestHandler=RequestHandler)

def myfunction(x, y):
    status = 1
    result = [5, 6, [4, 5]]
    return (status, result)
server.register_function(myfunction)

# Run the server's main loop
server.serve_forever()

Client code:

import xmlrpclib

s = xmlrpclib.ServerProxy('http://localhost:8000')
print s.myfunction(2, 4)

The server function returns a tuple

Answer 2

"in the C world, a function can return error code to represent the exit status, and use INOUT/OUT parameter to carry the actual fruit of the process"

1. Consider an exit status to be a hack. It's not a C-ism, it's a Linux-ism. C functions return exactly one value. C doesn't have exceptions, so there are several ways to indicate failure, all pretty bad.

   Exception handling is what's needed. Python and Java have this, and they don't need exit status.

   OS's however, still depend on exit status because shell scripting is still very primitive and some languages (like C) can't produce exceptions.

2. Consider in/out variables also to be a hack. This is a terrible hack because the function has multiple side-effects in addition to returning a value.

Both of these "features" aren't really the best design patterns to follow.

Ideally, a function is "idempotent" -- no matter how many times you call it, you get the same results. In/Out variables break idempotency in obscure, hard-to-debug ways.

You don't really need either of these features, that's why you don't see many best practices for implementing them.

The best practice is to return a value or raise an exception. If you need to return multiple values you return a tuple. If things didn't work, you don't return an exit status, you raise an exception.

---

Update. Since the remote process is basically RSH to run a remote command, you should do what remctl does.

You need to mimic: http://linux.die.net/man/1/remctl precisely. You have to write a Python client and server. The server returns a message with a status code (and any other summary, like run-time). The client exits with that same status code.