On Sunday, October 19, 2014 10:12 AM Simon Hausmann wrote: > I'm very fond of the idea of Qt making it very easy to talk to other > applications living in other processes on > potentially other machines (devices).
Me too ;-) > I think if we want to address this in Qt, then we should take three > requirements > very very seriously: > ... skipping #1 for a moment > 2) The system must allow for versioning. Not all devices/services/processes > will always be using the same "version" of the overall protocol. I agree, and I recognize this is one of many things that should be improved going forward. Same applies to types being passed by the protocol (as opposed to the protocol itself). > 3) The system should support a very convenient and robust mechanism to > discover and connect to other processes. I agree, and I'm a fan of zeroconf myself. But it needs to be optional, as I can think of cases where it would not be desired. So I see this as more of an extension/enhancement. > 1) Not everything is written in Qt. Perhaps only a GUI frontend? Or perhaps > some services are written in Qt and others > are written in a different language? > I think the key to success is to allow for interoperability across > language/runtime barriers. I agree in theory (who wouldn't?), but not at all in practice. Off the top of my head, I'm using: QIODevice/QDatastream/Q<type>Socket/Q<type>Server for communication QVariant for data marshaling MOC for Properties/Signals/Slots, including object introspection QEventLoop for event serialization, notification +More (container classes, qpa, etc) If the suggestion is to use/create non-Qt versions of all of the above, why use Qt at all? Or maybe I'm misinterpreting your suggestion? It doesn't sound like you are thinking of a wrapper, along the lines of PyQt/PySide, so I'm not sure what else you could mean. Please clarify. Also, your points on protocol buffers and limitations of QDataStream are more accurately issues with Qt itself, aren't they? Should they not be addressed directly in Qt, rather than only in a playground module? More specifically, why not incorporate protocol buffers directly into Qt's QObject/MOC? I'm not kidding here, the thought has occurred to me several times when creating custom qt_metacall() code. Within the MOC generated code, you have void * pointers, QVariants and static_casting to/from types relying on the auto-generated code to guarantee the necessary types. Why not have MOC auto-generate protocol buffer templates instead? You already need to compile the MOC output, which could compile the protocol buffer just as easily. Such an implementation would provide simple validation, improved type safety, and possibly a performance boost. It would remove the artificial/arbitrary 9 argument limitation (as in QMetaMethod::invoke). It would probably be overkill for DirectConnection, but would make sense for QueuedConnection, where you need to copy the arguments anyway. And it would also likely simplify/standardize QVariant and QDataStream as well. And then extending QtRemoteObjects would be a lot more straight forward. Brett _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
