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 <[email protected]> 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 <[email protected]> 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.
