Esteban, die mq in 0mq is misleading here because it is not a message queue. 0mq is called sockets on stereoids where you can plug communication channels with less overhead. It is more of an orchestration toolkit for distributed computing.
Norbert > Am 07.10.2014 um 20:54 schrieb Esteban A. Maringolo <emaring...@gmail.com>: > > Marten, > > I keep a close eye to MQ based architectures, because somehow they > feel "the best way" to implement interprocess/service messaging. And > also because I always wanted to implement something based on message > queues, just for the sake of it. :) > > However I don't find them suitable for interactive bidirectional > communication, but instead as their name suggest, queues. Ideally for > asynchronous communication, a "fire and forget" way of messaging. > If you go by the MQ path Sven implemented STAMP [1], which can work > with RabbitMQ's adapter [2] > > Unless you have an evented/callback based subscription to a queue, the > polling and message consumption from the queue itself will consume > about similar CPU cycles. What you gain using MQ is that you can > offload computation to other "worker images". > > Regards! > > > [1] https://github.com/svenvc/docs/blob/master/neo/stamp.md > [2] http://www.rabbitmq.com/stomp.html > Esteban A. Maringolo > > > 2014-10-07 15:18 GMT-03:00 itli...@schrievkrom.de <itli...@schrievkrom.de>: >> I have a little different view. lpgl is no real problem for me - it may >> be used for non-open-soure stuff without problems. Therefore I see no >> real problems with that. >> >> The other thing is: speed. And here it might differ a lot. I had written >> a heavy communication server in Smalltalk and with about 30 clients the >> Smalltalk process was CPU bound. No way to go. >> >> Introducing 0MQ and put all communication to an external thread and >> Smalltalk can fly again. That's the difference. >> >> Marten >> >> Am 07.10.2014 um 20:12 schrieb Alain Rastoul: >>> Thanks you for your answers. >>> >>> 0mq looks great, but released with LGPL licence, and I don't like that >>> (I don't >>> understand why there is also a GPL licence file in the distribution ? - >>> clearly a *noway*), >>> I prefer a full smalltalk implementation I can debug when things go wrong. >>> I think latency and timing problems would be the same, no big difference >>> in performance. >>> BTW knowing about this library is cool and may be of some help (who knows), >>> thank you Marten for the reference. >>> >>> I agree totally with you Sven about performance and standards. >>> And I also agree with you about reusing someone else's work ... >>> I don't like to reinvent the wheel, especially a good wheel when mine >>> would be worst, >>> I would if I were a wheel specialist - clearly not the case here. >> >> >> -- >> Marten Feldtmann >> >
