The main use case from my point of view would be getting the benefits of ZMQ inproc messaging patterns coupled with the expected C++ object semantics provided by QT signals.
The ability to give thread affinity to a QObject, effectively making any slot on that object be called in the same thread no matter where it was signaled, is phenomenally powerful. However, signals always go to all slots, so you can't do things like PUSH. On the other hand, inproc is also a very powerful interthread communication mechanism, but the need to serialize data to use it is a problem. You can send pointers around, of course, but then the problem becomes maintaining ownership semantics properly. So we have the power of patterns on the ZMQ side and the power of normal object semantics on the QT side. How can we bring these together? On Mon, Jan 27, 2014 at 5:00 PM, Justin Karneges <[email protected]> wrote: > Mapping ZeroMQ sockets to Qt signals/slots would be wild. :) None of the > existing libs attempt anything like this. I'd have to think more about > the use cases. > > On 01/27/2014 01:39 PM, Lindley French wrote: > > Question: One of the drawbacks of QT's signals and slots mechanism > > (which is otherwise great) is that it supports many-to-one (like ZMQ > > pull or sub) and one-to-many (like ZMQ pub), but it does't support > > one-to-any (like ZMQ push). > > > > Is there anything in any of these projects that addresses this in any > > way by merging the QT and ZMQ functionality somehow? > > > > > > On Mon, Jan 27, 2014 at 2:00 PM, Justin Karneges <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Goswin, > > > > On 01/27/2014 03:46 AM, Goswin von Brederlow wrote: > > > On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: > > >> There are a few options: > > >> > > >> https://github.com/wttw/zeromqt > > >> https://github.com/jonnydee/nzmqt > > >> https://github.com/jkarneges/qzmq > > >> > > >> It sounds like you've downloaded zeromqt. The project should > contain > > >> README.markdown. > > >> > > >> I am the author of QZmq and can help with it if you'd like. > > > > > > Can you give a few words of what makes each of them good or bad > > > please? Why did you start your own project instead of using on of > the > > > other two? > > > > It's been a year and a half since I created QZmq, so I cannot > remember > > the exact reason, but I believe it was because neither Zeromqt nor > Nzmqt > > supported fully event-driven reads and writes (at least at the time), > > and I didn't agree with the headers-only style of development used by > > Nzmqt so I thought I'd try my own rather than contribute. > > > > So the advantage of QZmq is it supports write notifications, and it > also > > includes a Valve class which makes it easy to implement backpressure. > > > > Probably one should choose between Nzmqt or QZmq. I believe Zeromqt > has > > gone unmaintained, and its own documentation suggests uses Nzmqt > > instead. > > > > Justin > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] <mailto:[email protected]> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
