openerp-expert-framework team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello guys, some feedback:

1) Don't you have like an API de facto standard in Python? Django, other?
Cause in OOOR we are implementing the Rails ActiveResource (inspired from
ActiveRecord) API http://goo.gl/HyBKd (with some things from ActiveRecord
that OpenERP API would support like relations or pagination). So it means
that any Rails noob having a read some introduction to Rails is able to code
using OOOR. I strongly advise you copy some existing standard instead of
trying to re-invent the wheel, cause we always see where re-inventing the
wheel leads; to temporary crap that should all be re-designed one day.



2) What is the license of this new openerp-client-lib lib? To
gain professional credibility, I think OpenERP SA should now stop kidding
with licenses and surprise license derogations grants once they accepted and
got a name thanks to hundreds of community contributions for years under a
given license, so did you decide a license for that new client library?
What is OpenERP SA view about the license of a such a client XML/RPC
library?

I'm not a lawyer and I could be wrong, but my view is that since the client
doesn't share any memory object with the AGPL code of OpenERP and only use
serialized text to request data from OpenERP, just like you don't need your
app to be GPL to write/read to a MySQL socket or just like you don't need to
be GPL to invok GPL unix command via shell, I believe the client-side
doesn't need to be AGPL. But of course, that would be good if OpenERP SA
could confirm it. It's no news that sometimes there are redundant tools
because of different licenses, so I think the place of your lib will in
party be determined by the kind of license it will offer.



3) About ActiveRecord API: yes this is a very good news: I always though
that OpenERP had a learning curve too steep due to its own hack ORM not
being standard. Of course this was a very good idea to built the bacth
orientation as a 1st class citizen into the ORM, but if you look at the
eco-system, it didn't need to be at the cost of a clumsy API without
ActiveRecord. For instance if you look at ActiveRecord in Rails, they have
nearly all OpenERP batch features via their "Relational Alegabra - AREL" and
it's even a lot more consistent, while they still offer an easy ActiveRecord
API.

I perfectly understand you won't change the API from one day to another and
his is okay for an ERP.

Now, I always felt the batch API has very strong limitations in practice:

   - because browse used to be so slow and may be with sub-optimal caching
   (I think Borja Lopez experimented on that, did you improved that in 6.1
   ?), in many many places we used to replace it by reads to get the job done
   at acceptable speed. For instance, it's possible that we change browse for
   read in the Brazilian localization in things like product_id_change on sale
   orders because if you consider all the super call chain, it ends up being
   very slow and hitting the database badly over and over. I'm eager to see how
   fast browse is in 6.1 to see if we need to do those hugly optimizations or
   not.
   - 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

here unless you manage to get in batch oriented (but I'm really not too sure
i's either useful either doable without redoing all OpenERP), I think the
ActiveRecord would make more sense. Of course, the more homogeneous you are
between batch and AR API (like Rails) the better it is to get learned to the
framework (the real bottleneck of OpenERP for all OpenERP professionals).



4) Finally, about the transaction thing: yes, WS transaction is hard to
achieve and I think it's perfectly reasonable you don't focus on that now,
there are much more urging stuff to do, like use your new lib in your
clients as a start.

One approach however I have been experimenting with OOOR was the following:
you could actually have on long pooling socket on some server where you
would have 2 clients subscribed (think node.js and clones): one being the
OpenERP server and an other being your client. Then it's like a GTalk chat:
those two are clients but communication happens real time with no latency.
AND, more importantly, you could then have OpenERP server behave as the
client of an OOOR or other clone being run as a server. Then what is
fantastic is that you can actually run that custom theoretically client code
INSIDE OpenERP transactions. With some little wrapping work, you could hence
like code module in any language you want (JRuby?) without any significant
performance impact and seamlessly integrated with OpenERP codebase and
within OpenERP transactions...
OK, I'm not sure I have been clear enough, doesn't matter. No something for
now, but possibly interesting in the future when we will have cleaned the
house before.


Regards and thanks for the standardization work (for me it matters much more
than spending time and resource building features on sand).


-- 
Raphaël Valyi
Founder and consultant
+55 21 2516 2954
www.akretion.com




On Fri, Sep 9, 2011 at 10:26 AM, Leonardo Santagada
<santagada@xxxxxxxxxxxx>wrote:

> 2011/9/9 Vo Minh Thu <vmt@xxxxxxxxxxx>:
> > Indeed one of our goal with designing a (high-level) client library is
> > to provide a consistent API server- and client-side. This is very
> > rough but Antony is thinking to head along the lines of this (also
> > very rough) experiment:
> >
> > client-side:
> http://bazaar.launchpad.net/~openerp/openerp-client-rpc-com-lib/rows/view/head:/sample.py
> > server-side:
> http://bazaar.launchpad.net/~openerp-dev/openobject-server/trunk-rows-vmt/view/head:/rows
>
> I still think oop api looks better overall, the one nice thing about
> this library is that taking names from an objet to do filtering you
> can use python operators (instead of __lt __gt and other hacks on
> oop). So one more thing to add to oop would be:
>
> ResPartner.filter(name__lt = 'Guido')
>
> could be
>
> ResPartner.filter(f.name < 'Guido')
>
> where can be a general object that would return an object when you
> operate on then that records the operation and the field name, later
> the filter function receive this objects and then have info like "is
> this field name valid?" and "is this comparison valid for this type?".
>
> :D
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>