Helo Cloves, nice to see to are still hanging around, some inline remarks:
The drawback is that for a brief moment, you lose synchronization - you've > got a new product on OpenERP and no product in Magento. But in most cases, > one can live with that. > Well yes, and today we already live with that. Because synchronization is slow and not guaranteed, today the catalog exportation, inventory exportation and shipping synchronization are all scheduled jobs anyway and these aren't any bottleneck even I would say in the current connector. > > The other major advantage, is that you decouple both systems. OpenERP need > not to know about Magento. All it need to know is that it must post a > message in a canonical data model (probably very close to OpenERP data > model) Nope, unfortunately, with its EAV tables and internal modeling Magento ends up with a pretty different data model and API than OpenERP. > to given queue when it create/update a product. The receiving part > (usually a thin adapter) need not to know about OpenERP, only that when a > message arrives in a given queue, it need to process the message. If you > ever decide to change Magento to Prestashop or Spree, no change to OpenERP > is necessary, you just have to change the thin adapter. > This is more or less what we do already, just change the interface by overriding things, even if we have no queue yet. It's only this way we were able to create a new Prestashop or OpenbravoPOS connector that quick.. > > BTW, I'm using ActiveMQ (JMS+Stomp) to integrate OpenERP, our legacy > manufacturing system and POS'es which are geographically dispersed on > crappy ADSL connections. That would indeed help increase the reliability and monitoring of these jobs as Guewen said. Overall, I would say that they are many things more important to evolve than the Queue API in these connector. Nevertheless, if it's contributed, it's still a nice to have thing. Also I totally respect the RabbitMQ module form Anybox. I just said once on Twitter that unfortunately, Magentoerpconnect and its dependencies is already a hassle to track and install, specially for non specialized third parties and this largely comes from the OpenERP naive module management system I already highlighted in other posts. Adding some 3 queue modules more and a new piece of infrastructure will certainly not help here although once installed the connector could be better. So eventually if we could reuse a simple queue built'in Postgres with the ability to send message upon in from outside OpenERP using some standard protocol, I'm all for that, I'm not sure yet the connectivity part is easy, I've seen a Ruby solution over Postgresql but none in Python. 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-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
