Le 08/11/2014 17:14, Sven Van Caekenberghe a écrit :
Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor.
I don't know what you are looking for, I would just do some prototyping and see what happens.
Thanks, somewhat what I'm thinking. To me , 'highly optimized C or C++' is not a clear advantage, because as you said, there is some network latency (although nearly none when clustered VMs are running under the same hypervisor and physical hardware), but also because other MQ systems are not all written in C or C++. Knowing that RabbitMQ is written in erlang and ActiveMQ in java, what do you think about Pharo here was my kind of question. I was also asking about networking or vm issues (processes, or sockets) you could be thinking of, if any ? May be the question was not clear or too broad, apologizes, this is my fault. About protocols, I tend to be focused on what I want to do and know I'm wrong here. Do you have plans about implementing more elaborated (and complex) protocols like openwire or amqp ? ... given that you are good at networking stuff, that would be great :) I have loaded your stamp package (very nice), and ran it against rabbitmq . If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? or should I publish my own package ? What is the best practice with SmalltalkHub and what do you prefer ? No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. TIA regards, Alain