On 10 Nov 2014, at 21:36, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Le 10/11/2014 20:52, Sven Van Caekenberghe a écrit :
Just for the record (I am being pedantic here, sorry): STAMP is a STOMP client, a way to connect to a message queue; but in messaging speak the parties are called producers and consumers, not client and servers (although this qualification can be useful architecturally); to run any code you always need both or not much will happen.
Sven
okok, didn't you forgot brokers ? I know but thank you anyway I should have untitled it 'Stamp, RabbitMQ and other MQ systems' not 'Stamp and other MQ systems', but the Rabbit went away, sorry :)
just that I'm thinking of writing a small STOMP server may be within the Stamp package. Because to me stamp was a package name not a stomp client, if your feeling is that it is a client may be this package should not have a server or server benchs in it?
I can put it outside, I don't mind, and the benchs too with the server (also that I do not want to break or dirty your work Sven) as I previously said, it has no sense from a client perspective. the benchs are done in that perspective : a way to compare performance of different servers, not to bench the stamp client performance (which is important too , but to do that I would have written the bench in java and C too, to bench Stamp client against java and C client. what I don't think I will).
mmm... I did well to ask
No, you misunderstood me. My point was that in messaging parlance a client is any party talking to the messaging broker or server. If you would be doing a server implementation, that would mean you are rewriting RabbitMQ, not impossible but quite a challenge ;-) Any self-contained (apart from the MQ itself) demo will always contain a producer and a consumer, or not much will happen, right ? Often you organise functionality in a client and server part. For example: testSimpleRpc | client server request response | "The server is a client listening on commands coming in on a queue named factorial" server := self client. [ server open. server subscribeTo: 'factorial'. server runWith: [ :message | | number | message body = 'quit' ifTrue: [ ConnectionClosed signal ]. number := message body asInteger. server sendText: number factorial asString to: message replyTo ] ] fork. client := self client. client open. 10 to: 20 do: [ :each | request := client newSendFrameTo: 'factorial'. request text: each asString. request replyTo: '/temp-queue/factorial'. client write: request. "Wait up to standard timeout for a reply" response := client readMessage. self assert: response body equals: each factorial asString ]. client sendText: 'quit' to: 'factorial'. client close Notice how both the 'client' and 'server', architecturally speaking, are actually STOMP 'clients', in the protocol sense of the word. So a benchmark or tutorial will fit in a separate category. Sven BTW, I am happy that you got up and running on your own. Your previous experience probably helped. Keep the feedback coming.