About RabbitMQ and others, I did quite some investigations and already use some (working with MSMQ in dotnet at work). I could spend months here but would not like to. My last question (in fact my real interrogation) here is especially to you, as the Zn developer, about a server implementation in pharo: not a true generic enterprise class server, a very small and simple dedicated server to start with, like Teapot is with respects to a big http enterprise class server. I don't really mind not following existing MQ protocols and RFCs (*), it would be dedicated. (*): except for the reusing part that of course has to be taken into account, for example websockets. Does it sounds realistic to you or totally undoable, and why ? Did you made experiments in that direction ? What would be your opinion, and do you have thoughts to share about that ? Thanks in advance Regards, Alain Le 08/11/2014 11:25, Sven Van Caekenberghe a écrit :
On 08 Nov 2014, at 11:21, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Perfectly correct, I agree, and do you have an opinion or pointers about building a streaming server in pharo ? queuing send/receives (nextPut:, next) from producers and consumers ?
Please start by reading https://github.com/svenvc/docs/blob/master/neo/stamp.md Don't forget to read a bit about RabbitMQ itself too. You can load the code and look at the tests.
Le 08/11/2014 11:09, Sven Van Caekenberghe a écrit :>
On 08 Nov 2014, at 10:56, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack what I am looking for is streaming (on top of a queuing server I presume).
RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers.
Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view.