>So, I'm returning an error but it's not an XML-RPC fault.
Yes. It's not only better than extending XML-RPC, it's the right
architecture anyway. Errors should be layered.
And you can be lazy and still provide adequate diagnostic information
to the human user if you get past the idea that errors should be
described by machine-understandable codes. In most cases, a program
looks only at whether a function succeeded or failed, and passes any
other error information on to a human. So, at each layer, have a
binary success indication and a detailed text message. As a failure
percolates up the stack, each layer adds its text explanation to
additional text explaining the context in which it failed, so that the
ultimate message that gets to the human user is a complete
explanation, without the code having to parse anything or be modified
each time a new failure mode is added to another layer.
That way, when the login fails, the response is a simple fault
response with a fault string that says, "Login failed because 1)
userid 'joe' doesn't exist and 2) password has invalid format - is
less than 8 characters." Because there's a fault, the program simply
abandons what it was doing and displays the fault string for the user.
In fact, ideally the "call" function in the client XML-RPC library
returns its own failures with text messages, and the caller doesn't
even have to distinguish between a failure at the server and a network
problem that prevents sending the RPC at all. In both cases, the
program sees a generic failure and displays an explanatory error
message.
Because some clients can make use programmatically of a breakdown of
error information (including at what layer the failure happened),
while others are just going to report to a human, I like to see
options (perhaps different methods/functions) for the client to
indicate what kinds of errors he can deal with.
E.g. the client program might be able to respond to a "file not found"
condition by trying an alternate file. In that case, the client
should call the "read this file or tell me there isn't one" method
instead of the "read this file" method, and if the file doesn't exist,
the RPC _succeeds_ with information in its result saying it
successfully determined that the file doesn't exist.
--
Bryan Henderson San Jose, California