Add a transport that makes use of QtNetwork

[estan]

I'm not sure if the library would allow for this, but it would be awesome. I think WAMP + Qt would make a great combo.

I know that you can use qtasio to have the Qt event loop drive an asio io_service, but I think the approach used by the author might be problematic (see comments towards the end of the thread).

First I thought of making my own minimal WAMP client library on top of Qt's network classes, but if it's in any way possible to leverage this library on top of the Qt event loop, that would be much better, since this library seems very (!) well designed and on its way to becoming featureful.

[ecorm]

If Qt provides the equivalent of boost::asio::io_service::post, then it should, in theory, be possible to use the basic Session API with a custom Qt transport.

A Qt-based transport would have to conform to the Transport and TransportBuffer concepts. You'd also have to write a Connector subclass that establishes a connection and creates such a transport.

The CoroSession interface currently has hard-coded dependencies on Boost.Asio. So I doubt it could be used directly with Qt.

Perhaps the best thing would be to write a QWampSession class that wraps a wamp::Session and provides a more Qt-oriented interface. It could make use of the facilities provided by QtConcurrent.

A WAMP client for Qt would be useful for those that want to provide a native UI that interacts with a distributed WAMP application (instead of web UI). It could also be useful for those wanting to provide a web UI for their Qt apps. It might also allow WAMP to make inroads on the Linux desktop, where DBus would normally be used.

[ecorm]

I should also add that I've been careful in limiting the use of Boost for only the transport layer and coroutine-based API. If someone was to provide a Qt-based transport, then the combination of wamp::Session + QWampTcpTransport should no longer have any dependencies on Boost.

[estan]

It's great to hear that you don't think it's out of the question. It's also interesting that you mention DBus, because what I'm working on now is an old DBus based solution for machine control, where it was realized that remote control was a requirement. The solution I'm building is based on WAMP components instead.

At the moment we're using qtreactor and Autobahn|Python for the GUI parts, but it's nice to know that this kind of extensibility is kept in mind here, since we're thinking of moving to C++ for some of the GUI components.

For some more background: The machine we're building is for mineral analysis of drill cores, and it has a full blown Linux machine sitting in it. The previous solution for controlling the machine was a set of DBus services for each of the hardware components. But this was never really a viable solution outside of development, since in the end we'll need remote control from the GUIs used by the geologist to control the machine (he'll have one in his office, and one will also be placed down in the mine which the drill operator will use to do analysis of cores as they are taken out of the drill hole).

[estan]

And also thanks for all the pointers on how this could possibly be implemented. I'll keep those in mind, should we go further with these plans in the (not distant) future. The machine we're building has a planned launch of Q1 2016, so I think we'll be finalizing the control software some time this autumn. If you feel like you want to close this GitHub issue to keep the issue list under control, that's perfectly fine. It's been nice to hear your view on it.

[ecorm]

I've briefly looked into how one would emulate io_service::post in Qt, and the closest thing seems to be QtConcurrent::run. wamp::Session is currently not thread-safe, so care would be needed to ensure that only one thread accesses it at a time.

Also, Qt does not directly support the notion of asynchronous callbacks. Signals and slots would not work very well for operations like Session::call or Session::subscribe. The most promising approach seems to be QFuture.

It seems highly likely now that there would need to be a wrapper around wamp::Session that provides a Qt-friendly API.

As much as I love Qt, I'm wondering if a Qt transport + client API should rather be implemented as a separate project that uses CppWAMP as a dependency. For example, Qt developers might prefer QVariant over my home-brewed Variant class. I'm worried that I'm going to end up having to maintain two libraries in one: a Boost-flavored WAMP library and a Qt-flavored WAMP library.

[estan]

Absolutely, this was not really an ask to implement this in cppwamp. Let's just say I've now put it on your radar that it would be nice to be able to wrap this library in a Qt-ish interface (including making use of the Qt event loop instead of Boost Asio). Thanks for taking the time to look into possible avenues here, now I know at which level such a thing would probably live.

Yes, when I was considering writing my own Qt WAMP library I was definitely thinking of making it as "Qt" as possible, including making use of QVariant.

Update: To clarify, yes probably a separate project is the best idea. I only ask to keep in mind that it would be nice to be able to make a Qt library that makes use of CppWAMP. If that would in turn stretch the library to be too extensible and be too much of a maintainance burden, I'd understand that, and a separate WAMP implementation on top of Qt's network classes might not be a bad idea after all. But if it's possible to keep the door open, that would be great.

[ecorm]

If you end up implementing this, and there are minor changes to CppWAMP that would make your life easier, please let me know.

[estan]

Yep, will do.

[dridk]

Qt support know Qwebsocket