@cjalmeida
> * Move to the JVM using Jython. I wish this too. I mean at least Jython support. By removing deprecated XML lib, Tiny would also gain much easier distro packaging (especially for Windows) and thus better overall product image. Those who do not want to see the benefits (and coming perf gains) of the JVM will still run on JIT disabled C Python, no problem with that. I'll track progress here: https://blueprints.launchpad.net/openobject-server/+spec/jython-support-as-jython-improves > * YAML instead of XML I vote for that too. Especially as the WYSIWYG designers are not mature enough yet and because we integrators always en up writing lot's of XML to cheat the framework. I even created a blueprint for this months ago: https://blueprints.launchpad.net/openobject-server/+spec/pyyaml-yaml-data-import > * Option of building modules using Scala (and being statically typed) Once on Jython you could invoke whatever JVM language you like from an OpenERP module. Currently, integration between JVM languages are not yet like the .Net object sharing abstractions, it's much more low level procedural bindings. But the JVM guys are organizing themselves, some JVM languages said they are committed to adopt the new MOP (Meta Object Protocol). However such support is for the end of 2010 at best. Now, core things in OpenERP could have been coded statically, provided you had a statical language as powerful as Python, which is certainly not the Java language bit could have been Scala or Clojure. I doubt the dynamic camp move to such engineering though. Anyway a good test suite could finally be build on such a large project, and hopefully language perf will be good enough already on Python in front of SGBD perf. > * A really extensive suite of unit and functional tests (no regressions!) I vote for this too. At least Tiny built the continuous integration server infrastructure now. Hope they streamline the test writing process. In my opinion, supporting YAML, would also be part of the answer as it would allow 3x less typing to create markup based tests. > * Forget the one-software-to-rule-them-all mentality. More brainpower > dedicated to integrating with existing functional solutions. (Pentaho for BI > and ETL, Magento, SugarCRM, interfaces for HR, POS and Tax software > integration) I vote for this too. However, integration is usually harder than what people think at first (supporting versions changes, failures, security, configuration, constructing a double referential, mastering heterogeneous runtimes and dev environments, realtime/batch bidirectional webservices...) . So I agree to tell that currently Tiny thinks too much about OpenERP running the world alone but I ask for a balanced approach because in lot's of situations, rebuilding the feature in OpenERP is indeed cheaper than paying the cost of integration. It very much depends on the "adherence surface" between the systems. On the contrary, integrating payroll from Saas cheap and correct solutions is sometimes so easy that you would never want to recode it in OpenERP. BTW, I'm spending my time new teaming with Sharoon Thomas (Openlabs.co.in) to rebuild the Magento connector we prototyped at Smile. But hey Magento sucks. I'm eager Spree kicks its ass and going with Spree instead. As for SugarCRM, I'm not sure, but I think OpenERP could quickly beat it natively as CRM is improved, may be during 2010/2011. Also I'm sure, the Sugar platform is nothing like Openobject one (so they will hardly resist) and the SugarCRM interface is not all this sexy past the few Flash graphics. Or even if Sugar will do much more out of the box, OpenERP could still win because it would more easily adapt to your real requirements provided little module coding and because of superior and immediate integration. Dream mod off, back to Magento connector ;-( ------------------------ Raphaël Valyi CEO and OpenERP consultant at http://www.akretion.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=44123#44123 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
