[Time] Name | Message |
[08:22] CIA-15
|
zeromq2: 03Martin Sustrik 07master * r235ed3a 10/ (10 files): signaler transports commands per se rather than one-bit signals - http://bit.ly/aQglHI
|
[08:37] CIA-15
|
zeromq2: 03Martin Sustrik 07master * r3f5465a 10/ src/signaler.cpp : Windows port fixed - http://bit.ly/aJDsub
|
[19:27] sustrik
|
cremes: do you understand what's Matt is actually asking for?
|
[19:29] cremes
|
sustrik: i think so
|
[19:29] sustrik
|
can you give me some insight?
|
[19:29] cremes
|
i think he wants to be able to attach callbacks for specific messages sent via a socket
|
[19:29] cremes
|
so let's say he has one PAIR socket open...
|
[19:30] cremes
|
if he sends 3 messages over that socket, i *think* he wants to be able to associate different callbacks with each sent message
|
[19:30] cremes
|
hmmm.. perhaps that works better with a REQ socket :)
|
[19:30] sustrik
|
how would the library know which callback to use for a particular message?
|
[19:31] cremes
|
it would probably need to be part of the body of the message, e.g. a reply_to field
|
[19:31] cremes
|
so that it can be matched
|
[19:32] cremes
|
again, this is just my guess as to what he wants
|
[19:32] sustrik
|
hm, that's what REQ/REP does under the cover
|
[19:32] sustrik
|
anyway
|
[19:32] sustrik
|
thanks for a hint
|
[19:32] cremes
|
REQ/REP does the message routing only at the socket level; he wants message-level routing would be my guess
|
[19:33] cremes
|
s/routing/matching/g
|
[19:33] sustrik
|
something like subscriptions?
|
[19:33] cremes
|
yes
|
[19:34] cremes
|
i'm going to post to the blog again asking Matt for more details...
|
[19:34] sustrik
|
ok, thanks
|
[19:42] cremes
|
sustrik: having reread the thread, i was mistaken what he is looking for; i think he was asking for an alternate to zmq_send
|
[19:42] cremes
|
something like: zmq_async_send(socket, msg, flags, callback)
|
[19:42] cremes
|
that variant would call zmq_poll (or similar) behind the scenes and invoke the callback when data arrived
|
[19:43] cremes
|
i think he wants to avoid the explicit zmq_poll operation in application code; let's see what he has to say on the blog assuming he responds
|
[19:54] sustrik
|
ah, that makes sense
|
[19:55] sustrik
|
in other words: automatic pairing of requests and replies while retaining the possibility to have multiple requests on the fly at the same time
|
[19:58] cremes
|
sustrik: yes, i think so
|
[19:59] sustrik
|
that would make a nice little project...
|
[19:59] sustrik
|
few hours or so of coding i would say
|