Merge lp://qastaging/~akretion-team/openobject-server/xmlrpc-fixes into lp://qastaging/openobject-server

This is an awful hack.
The behavior will be different between clients...

The way OpenERP reports errors to clients can be updated to provide a real FaultCode that mean something (maybe depending of the Exception type).

Christophe, I agree that OpenERP can eventually workaround fault numbers,
but this is a much larger work (eg I can't do it) that involves changing the
existing GTK and web clients.
So I mean, I suggest OpenERP S.A. work on fault numbers in the long run of
course.

But in the meantime, we really have to make v6 more XML/RPC compatible: the
current situation with non Python libraries is terrible as people report it
in the tracker.
So what do we do, nothing?
I suggest we don't do nothing. Look currently what kind of trickery non
Python clients have to do to try to catch OpenERP errors: this is what we do
in OOOR (the most advanced around I think):
http://github.com/rvalyi/ooor/blob/master/lib/app/models/open_object_resource.rb

    #grab the eventual error log from OpenERP response as OpenERP doesn't
enforce carefuly
    #the XML/RPC spec, see https://bugs.launchpad.net/openerp/+bug/257581
    def try_with_pretty_error_log
      yield
      rescue RuntimeError => e
        begin
          openerp_error_hash = eval("#{ e }".gsub("wrong fault-structure: ",
""))
        rescue SyntaxError
          raise e
        end
        raise e unless openerp_error_hash.is_a? Hash
        logger.error "*********** OpenERP Server
ERROR:\n#{openerp_error_hash["faultString"]}***********"
        raise RuntimeError.new('OpenERP server error')
    end

So I mean, I don't understand your argument: yes this is a hack (to keep
backward compat otherwhise you are welcome to break it as I suggest), but
you have to consider that the current situation is way much more hacky.
Consider this is the code I've done with a good knowledge of Ruby + OpenERP
+ time. Java guys for instance simply just fail on this entry barrier
because OpenERP doesn't respect the XML/RPC spec (take a look to the
forum)...

Also, currently, the GTK and web clients don't interpret the string error
code at all, they just display it. Having a number instead wouldn't change a
lot of things (and consider the current patch doesn't touch teh existing
clients). If you would like to have that error code for the client, well may
be we could just aggregate it with the stack trace in the second string
argument. I let you decide that, it depends if you want to touch the GTK and
web clients.

So, sorry, but I insist, waiting for other arguments. I continue to suggest
merging rather than doing nothing for v6 (now if OpenERP wants to do better,
this is welcome).
And remember: the perfect is the enemy of the good, specially in the open
source field when you should count on free community contributions to
improve the product continuously (otherwise you should finance it all,
driving no big advantage over closed source in term of TCO for the
customer).

Raphaël Valyi
*http://www.akretion.com* <http://www.akretion.com>
[image: logo_only_17 (another copy).png]

<http://github.com/rvalyi/ooor/blob/master/lib/app/models/open_object_resource.rb>

On Fri, Jun 18, 2010 at 4:56 AM, Christophe (OpenERP) <
<email address hidden>> wrote:

> Review: Disapprove
> This is an awful hack.
> The behavior will be different between clients...
>
> The way OpenERP reports errors to clients can be updated to provide a real
> FaultCode tha...

We keep the bug open for the future, but this specific patch cannot be accepted, so I close the merge proposal for cleanup.