openerp-community team mailing list archive

[Antony Lesuisse <al@xxxxxxxxxxx>]

On 11/09/2013 04:06 PM, Raphael Valyi wrote:
>     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.

openerp CMS is not related to the web client, it's more a server side 
framework to generate static web page, where the web client is a fat-client 
javascript application.

>     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?

I never said that, i think that using t-field's, t-esc's and jsonrpc 
serialisation for rpc calls makes openerp cms against most XSS attack. But you 
are right we need to assess and scrutinize website-al from a security point of 
view. DOS have the potential to be more problematic, i think this could be 
handled at the route level by using the workers --limit in multiprocessing 
mode. Or maybe by a proxy before openerp. Any suggestion are welcome.

> 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.

I dont really know aktoor or any of your ruby library, so my opinion is 
irrelevant on this matter, i'm sorry if i offended you, i respect the many 
contributions you have made to the openerp ecosystem. My point was that 
openerp will soon provide everything needed to build powerful web apps, if 
everything works out of the box there is less incentive to use additional 
layers. More on this below.

>     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?

I dont get it, i think openerp cms is something new because it combines the 
sets of functionnal application we already have with a easy to use http layer 
to implement the front end part of those application. Before that you had to 
develop the front-end in php/ruby/... and interact with openerp using xml-rpc. 
Moving this php/ruby logic into openerp makes it easier for developer IHMO.


>     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.

Yes i get your point we need to address this.

> 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.

As i said before portal/website user are not counted as OE users, only 
employee are, this pricing is simple there are no plan to change it.

> 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)


MMmh not sure about this, use case may vary much, we target medium websites, 
our website already runs on openerp with 20k visitors per day with an average 
loadavg of 0.19.

Website with more than 1M visits per day might be outside of the scope of the 
plain openerp cms. During the community days i talked with somebody who 
implemented the angrybirds shop they had 60 new visits per second and they did 
a lot of specific devs to optimize the experience, they use varsish a lot. I 
think caching can help a lot for those use case.

Extreme use case somtime require extreme solution, but on an other end twitter 
has been running plain ruby on rail until very late and you know what we all 
think about premature optimizations.


> 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...)

This point is too confused, but about BI we are working on a new tool (again) 
this one is simplier and reuse and improve on the existing ORM group_by. I 
manage the RnD and i'm glad that Research is part of it, i think it's sane to 
explore new things. Google killed a bunch of "non-succesful" projects, i 
probably many more internally, it's normal, progress is exploratory.

> 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.

I'm also eager to see what will happen, we'll see.

> 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.

Off course i encourage you to explore new horizons this was not the point of 
my mail.