RFC: smart server protocol change for 0.16

[Andrew Bennetts]

Martin Pool wrote:
[...]
> 
> I think in general if an error occurs on the server it should be
> re-raised on the client.  Since we can't and don't want to marshall
> arbitrary Python objects this may be a bit of a puzzle.  But most
> exceptions have only a dict of string parameters, and passing the
> classname plus that dict may be enough.  For exceptions that are
> unexpected or unrepresentable we could pass a string form.

I think it's best that all errors go through explicit
serialisation/deserialisation, and if an error occurs that is not explicitly
handled, then a generic error returned to the client (and a full traceback
logged on the server).  This is analogous to "500 Internal server error" in
HTTP; you generally don't want to send details of what broke in the server over
the wire in case it exposes sensitive information.  It would be fine to have a
debug flag that defaults to off that will optionally send details of the
unexpected error to the client (like how some Python webservers can be
configured to give tracebacks), but only as a development aid and never for
production.

This policy will also discourage clients from relying on accidental details of
these errors, although I guess while bzrlib is the only implementor of this
protocol that's not a big issue.

The downside of course is that sometimes a client will get fairly useless
"something broke in the server but I can't tell you what" error, but we should
be striving to make unexpected errors almost unheard of.

-Andrew.