openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello Antony, inline answers:


On Sat, Nov 9, 2013 at 11:29 AM, Antony Lesuisse <al@xxxxxxxxxxx> wrote:

> huh, what are rambling about ?
>

Not "rambling", just presenting an innovative solution to what Mario was
asking for.

>
> [...]
>
> I might be wrong, but it looks, to me, that this branch will obsolete your
> work on aktoor, except for projects where people want to mix two
> frameworks, openerp/python and rails/ruby.
>

I never made AKTOOOR to replace the OpenERP web client as I said. Indeed,
it's more for people that will want to mix the frameworks indeed.


> Avoiding mixing frameworks was one of the key motivation behind the
> project, as i believe that the more unnecessary layers, the more bugs.
> OpenERP is now schematically HTTP (session, db matching, auth) ->
> Controllers (using html views) -> ORM. All the security is handled by the
> ORM we dont trust views nor controllers.
>

Ahahah ahahahah. "All the security handled by OpenERP", this statement
alone makes the whole argumentation doubtful.

Sorry, but I'm pretty sure that Rails/Devise is a bit more battle hardened
than OpenERP in term of security.
It really have a few more real millions of users and millions of $ of
startups all hardening it for a few years without having to discover a
business model first.
I'm curious to see all XSS and DOS exploits that will be found against
OpenERP powered websites in the wild. Come one, you have never been a web
publishing technology, why not trust the work of those who have been
instead? OpenERP SA is smarter than everybody else, is that the theory
again?

So I really defend my choice of having front-end users handled and
primarily authenticated in Devise (or externally via oauth) and OpenERP ORM
security only applying second atop of that.

You may think it's more bugs. But I really doubt about that: OOOR core is
only 500 lines of code, OOOREST 400 lines, AKTOOOR around 400 lines also.
OOOR has a high test coverage, it's just a kind of web-client like the web
OpenERP project. Nothing more either.
All the rest, Devise, Rails, simple_form and co have a much higher test
coverage and user base than OpenERP. So mixing the two things inst'
necessarily more bugs. Just like may be it's was less bugs to plug OpenERP
and Magento/Prestashop than try to redo them in OpenERP with its little
community of its own.


>
> The changes to OpenERP are minimal: we introduce a new ir.ui.view type,
> the controllers layer has been improved (already in trunk) and that's it.
> Website define a new public user (like anonymous) this user is used when
> you are not loggued. Please check out the code.
>

I know that.
I also have the concept of public user in OOOREST. It's mapped as a single
OpenERP user too. See last section at
https://github.com/akretion/ooorest (while
I should certainly document it more).


>
> And now the shocking news: as the project is now in bugfixing mode,


You mean we are approaching the new SorrySAP campaign? SorryGoogle this
time may be then?


> we will start to write the documentation, and lower the barrier to
> developement with an easy quickstart guide and some scaffolding tools. The
> reason is that now we have a full stack framework we want to make it more
> friendly to newcomers. Documentation is now an high priority project,
> everybody can rejoice :)



This is all welcome really.

But sorry I still think my Ruby/Rails bridge can be extremely useful. Here
are a few reasons again:

1) license:
your whole framework is AGPL. And double license is never welcomed in a
community project receiving tons of third party contributions like OpenERP.
I like AGPL very much and defend it, but it doesn't match all business
models. Startups wanting to create the new web2.0 websites aren't really
enjoying the idea that all their users (potentially their competitor) will
ask for the whole code or put them in justice.
Instead by bridging a MIT Rails project, you can invest on a non AGPL
website and still use OpenERP (and yes then publish the OpenERP modules).
That is a startup can still protect some industrial secret and get its
investment protected.
The AGPL license of OpenERP is absolutely cool to avoid that VC capital
hijacks the projects and close it or spoil it after exploiting community
work to build the ecosystem. So don't get me wrong, it's the social
contract of the community and I absolutely defend OpenERP AGPL license for
the ERP side.
But I just open new horizons without breaking the social contract.

2) OPW compatibility
you say that you have a light user concept. Sorry, but as for the OPW, we
hear quite some big companies that would appreciate having say 1000 "light"
non read-only OpenERP users with having to pay a 39 euros/months OPW for
them all. Today if they think Enterprise OPW is important, many tend to
just drop OpenERP from the short list (and consider not all countries will
invest as much in IT).
With my work, they can have a single ERP user whose behavior is restricted
by the current partner they are associated with with their login. While
they aren't full blown users, they aren't just readonly users, they can
even be employees.
I think this answers to the concern Mario was initially asking for.


3) scalability:
OpenERP has a transactional relational database with a borderline ORM that
isn't really exemplar on how it makes SQL queries (though yes it avoids the
n+1 issue like most do also anyway).
If you wants millions of users, sorry but you'll have to think about some
good hardware...

To give you an idea, the website I'm building is targeting millions of
users. So in fact anonymous users don't hit OpenERP at all except when
warming up OOOR moneta backed cache may be.
And some OpenERP collections are cached in Apache SolR in my case (product
catalog). That means bridging Rails gives you big data scalability for
free, while logged in users still OpenERP without the trouble of data
duplication.
And even when one OpenERP wouldn't make it behind, I can actually shard
over the OpenERP instances: I can have several of them. For instance, in
the project I work with that should over all Brazil, it's already designed
so that we could shard the OpenERP users over some 50+ different OpenERP
databases.
(you know I worked on some of the largest OpenERP projects around, I know a
bit that it has scalability issues and this is a bit normal for an ERP -
and I also had dinner also last Wednesday with the ThinkOpen guy behind the
project with 150 000 read users in Portugal, I hear about the catches of it)

4) sustainability:
Look twice how all that OpenERP core is made (talking only about the core
which this new website belongs): only OpenERP SA pays the R&D of this and
makes the commits (and only SA hold these copyrights). Meanwhile, people
believe you are creating liabilities towards VC's capital to sustain that
because no sorry, we don't buy that there are millions of OpenERP users and
that your little number of rotating SaaS users would fund all that already.
Or may be you also disrupted even the concept of "break even", who knows.
Come on what is the pay back of that mortgage? How will that magically
become sustainable?
Sustainable open source, is all about synergies to share costs, it has
never been about VC concentration and re-inventing the wheel.
I wish I'm wrong on this, but this is what I believe.

Reusing the mature Rails ecosystem instead is 100% sustainable: I'm just
reusing mature things not eager to get a return on what they are betting
now.
Sorry but in the past people had so many example of non sustainable things
written by OpenERP SA that I won't really want to sign a new blank check
here (MySQl branch, ETL modules, Dia RAD editor, BI tools, Openoffice
Designer, wiki module, google connectors, integrated ecommerce, first
web-clients frameworks...)

5) freedom:
OOOREST just gives you a REST way to interact with OpenERP, then you can
use whatever tools you want atop of it. For instance we had picking
application using Sencha Touch running atop of it since v6.1.

6) synergies:
let's see where your CMS goes. But given the business model limitations,
it's very low developer base, and it's intrinsic scalability issues, I'm
not as optimistic as you.
Instead once I had OOOR and OOOREST, I can have almost the same thing for
free in a CMS like LocomotiveCMS (again something that is big data
oriented, backed by MongoDB): I can have a shiny CMS with OpenERP objects
as if they where LocomotiveCMS objects without having to re-invent a CMS.
Same goes for e-commerce.


So, I'm not wanting to fight about the web-client choice. Your work on the
web-client is very much appreciated really, I just defend my choice to open
new horizons for free instead of trying to re-invent the world around
OpenERP ORM and panic how we may make pay it back.


Regards.

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com