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
