openerp-expert-framework team mailing list archive

["P. Christeas" <xrg@xxxxxxxxx>]

On Friday 09 September 2011, Raphael Valyi wrote:
> Hello guys, some feedback:
> 
> 1) Don't you have like an API de facto standard in Python? Django, other?

I think there is no standard API. And if you ask N coders, you will get N+m 
answers about what they prefer to be the best coding style.

All I have done was to design *layers* in the libclient, so that we have

[ High level API, OOOP style, or whatever ]    (to be implemented)
         | |
[ RPC layer ]   ( the one the server exposes, functions, same as in Gtk etc)
         | |
[ Protocol layer ]    (XML/RPC*, Net-RPC, RPC-JSON, Pyro etc.)

So,  each layer can be expanded/replaced as appropriate. 


> 2) What is the license of this new openerp-client-lib lib?

In libcli: LGPLv3, clear, no hooks or twists or anything. 


> 3) About ActiveRecord API:  ...
Once the RPC layer supports some transactional logic, anything would be 
possible. Some experiments towards that direction are already done.
> 
> Now, I always felt the batch API has very strong limitations in practice:
> 
>    - because browse used to be so slow ...
  Well, only in official 6.x series ;)  What Borja did, was already implemented 
in the pg84-next. With these (either of the solutions), "browse" is a better 
choice than distinct read()s, more efficient, too .

>    - yes, OpenERP is quite batch oriented and this is nice, but many
> things, even on the server side are not batch oriented at all, mostly:
>       - on_change that allways apply to one record and still un accross the
>       browse loop bloat
>       - workflows signals and actions
These have to do with poor coding. When you are called like "on_change_foo(cr, 
uid, ids, args, context)" you are really expected to operate on all of 'ids', 
not only on the first one!
Again, the browse bloat is already gone.

> 4) Finally, about the transaction thing: yes, ...
> One approach however I have been experimenting with OOOR was the following:
> you could actually have on long pooling socket ...

Well, all aproaches are considerable. The bottom line is, however, that the 
server will need a significant change, before it allows multiple RPC calls in 
the same db transaction. And then, more issues will emerge (keep my word for 
that).
If you see the examples at "libclient", you will notice dummy little scripts 
that don't care about transactional safety. In "buildbot", these operations 
that need atomicity are moved to the server side[1] and done in a single RPC 
function. So far, avoided the big change.


[1] once you code a few lines in the client library, it is easy to add the 
"(cr, uid.. " prologue to functions and move them to server side.


-- 
Say NO to spam and viruses. Stop using Microsoft Windows!