IRC Log


Tuesday May 4, 2010

[Time] NameMessage
[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