On 12/6/06, Daniel Rall <[EMAIL PROTECTED]> wrote:
> For historical reasons, void methods are currently unsupported. In > other words, as a workaround, change the method to return an int and > everything should be fine. You may also file a bug report to have this > changed, at least if extensions are turned on. Jochen, what about mapping this automatically to a basic or empty return value (e.g. empty struct, integer value of 1, etc.) even when extensions are not turned on? This wouldn't be in violation of the spec, only a difference from the original XML-RPC implementation. When in extension mode, we could return some type of nil value, which would be an actual protocol extension.
I understand that this is a trap, in which one can fall very easily and that your suggestion provides a way how to avoid it. I am unhappy, though, about the consequences in code. The places where "void" is being detected and where return values are handled are currently completely unrelated. Question: How was this handled in 1.2, or 2, when null values haven't been supported? If these versions did as you suggest, then I'd be open to always return "" rather than null, if extensions are disabled. Otherwise, I'd suggest we leave things as they are. Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]