A Divendres, 22 de juliol de 2011 11:27:19, Cédric Krier va escriure: > On 22/07/11 10:45 +0200, Albert Cervera i Areny wrote: > > A Dimarts, 19 de juliol de 2011 10:56:14, Cédric Krier va escriure: > > > On 19/07/11 09:56 +0200, Borja LS wrote: > > > > El 17/07/11 11:51, Cédric Krier escribió: > > > > >proposal to drop NetRPC for jsonrpc > > > > > > > > What about using Pyro instead of NetRPC? > > > > (http://packages.python.org/Pyro/) > > > > > > I don't know Pyro but it seems to be design to work with Pyro object on > > > the server side. This means that it requires to modify a lot of the > > > server to match the Pyro concept or to use just one proxy object but I > > > think we will lost a lot from the coolness of Pyro. > > > > > > > NaN used it for Koo (KDE based OpenObject Client) with great success > > > > (is much faster than NetRPC over high latency networks). > > > > > > I think this is due to a bug in NetRPC which we fixed in Tryton a while > > > ago. And perhaps Koo uses some async calls which could hide the > > > latency? > > > > We use async calls in Koo but not using Pyro's mechanism. > > We had a talk in B2CK about async calls in the client but we find that it > was not right because if we do so we must any way freeze the GUI to > prevent any change from the user. > Let's look at an example: > > The user modify a field that has an on_change call. The client starts > the on_change call and directly gives back the hand to the user. The user > starts editing the next field. During the edition, the callback of the > on_change is triggered and it must change the value of the field the user > is currently edited. What should we do? > > For me, it is better to work on having request calls very fast to prevent > the user to wait but async calls will just hide the problem. > > And other thing that will be good to have thread-safe rpc calls. For now > there is a lock for each call which means that only one rpc call running > at a time. There is already some background rpc calls like the one to > fetch the number of attachments of the selected record but I think we > could have more if we could have multi-rpc call at a time. This should be > possible because the JSON-RPC syntax allow to pass an id to the request.
I agree. In Koo async calls are rarely used. They're used for the number of pending requests and in wizards (in Qt only the main application thread can update the GUI so we must do RPC calls async). What it would be very good is if we only blocked the current tab, so one could have a pending request per tab instead of per-application. Unfortunately that probably requires too many changes but it would be a great improvement. -- Albert Cervera i Areny http://www.NaN-tic.com OpenERP Partners Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
