Re: How referees should respond to illegal plays

Jason McIntosh writes:
 > Secondly, fault packets simply can't hold very much data (so long as 
 > they stick to the XML-RPC standard); the code has to be numeric and 
 > therefore not immediately human-readable, and it can't contain any 
 > arguments.

That's not true, RPC faults have both an integer code and string.  And
I think it would be okay to insert our own subelements to the fault
XML (in the Volity namespace) if we really need something more
structured than a string.

 > That is, the ruleset would define a set of referee-to-client 
 > RPC requests that would handle every possible error condition.

I don't think I like this.  It's too asynchronous.  It seems natural
for an erroneous request to result in a fault response, but it would
be a pain to have to set up a handler for error "requests" that can
come at any time.  What do you propose should be the result of the
original request, if not a fault?  If you don't like using/extending
RPC faults, how about coming up with our own error structure that
would be returned as the (non-fault) result?

--dougo <at> place.org

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20