Am Freitag, den 22.07.2011, 12:49 +0200 schrieb Albert Cervera i Areny: > 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.
+1 would be a really 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 -- Korbinian Preisler ____________________________________ virtual things Preisler & Spallek GbR Munich - Aix-la-Chapelle Windeckstr. 77 81375 Munich - Germany Tel: +49 (89) 710 481 55 Fax: +49 (89) 710 481 56 [email protected] http://www.virtual-things.biz -- [email protected] mailing list
