Hello Antony, inline answers:
On Sat, Nov 9, 2013 at 11:29 AM, Antony Lesuisse <[email protected]> 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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
