Re: [Development] QtRemoteObjects (was Replicant)
Sayeth Simon: On the other hand I think it is critical for Qt's success to also support use- cases that leave our little universe (of Qt). And that means either building something yourself and convincing others to adopt it or adopt a technology/approach that already has existing mind share. For distributed objects architectures I do like the idea of supporting wire formats that have existing mind share and I also do think it is very important to make the programmers aware of the distribution. Respondeth Brett: Sure. I agree in concept. But how are you suggesting we go about this? My resistance comes from several factors: 1) I think what you are proposing is what D-Bus brings to the table. By focusing on the Qt side, I think remote objects is easier to use than D-Bus, but is also not seen as competing with it. You risk both by making it more general. 2) What you are proposing is a massive increase in scope, which obviously takes a lot of time/resources to accomplish. Is Digia offering to help? 3) As stated, the existing code is spread throughout all of Qt. I assert that any new wire format support needs to be spread throughout Qt as well. Otherwise you have a maintenance nightmare trying to keep up with changes to all of the various types of objects. Unless you have a solution I'm not seeing, I think the best thing to do is try to future-proof remote objects so such a change is possible down the road. Agree with Brett. I think this is a vision/mission thing, as D-Bus and QtRemoteObjects are doing different things, but as noted there happens to be some overlap. Regarding the future-proof, I'd vote on a plain-text serialization/synchronization of QVariant across the wire, possibly with user-data type extensions for custom plain text to/from for state serialization across the wire. Plain text tends to be quite robust, and future-proof, and it's often useful for debugging anyway, even in the case where a binary protocol is available. Good examples are things like date and time and color -- the plain text version is well-understood and forever future-proof, independent of native binary storage. Most of the automation and LIMS systems (lab information management systems) actually stay plain-text for production, and that's what they use in production to simplify integration across vendor devices and instruments. It might not be practical for high-speed/high-volume data to be plain text, but most systems aren't that. QtRemoteObjects sitting on plain text (like JSON) might enable alternative foreign-point implementations (such as for other non-Qt libraries or languages). Just guessing/speculating. The most ideal might be a slow-plain-text protocol, and a fast-binary protocol, where the user can toggle between them based on their need-for-speed. But, of course, that's double the work. ;-) So, I think there are really good points here, but my intended first use is QtRemoteObjects with Qt on both sides for transparent synchronization. In this case, I actually don't care about the details. I want the library to do all the cross-process details, so I don't need to. That's what makes it really shine as a novel high-value thing, IMHO. Further, if we did this, I could still write MyProprietaryLib on the foreign-point to hook into other systems. It would link Qt, and expose the QtRemoteObjects API through my new API using MyWeirdLanguage. Regarding the foreign-point not linking Qt (such as for embedded where no Qt might be available), yes, we're back to discussing something like a plain-text protocol where someone could re-implement using that protocol. snip, This is clearly something where philosophies and opinions differ, so a perfect subject for a healthy debate of what we should focus on in Qt, as we try to to make software development easier. I think the discussion needs to be whether Qt will accept an alternate or additional method of marshalling data types. But I guess that is up for debate! I'll follow discussion here closely. My impression is that we'll eventually need/want to centralize marshalling/serialization for QtRemoteObjects, possibly eventually allowing user-custom-type extensions for synchronizing custom user-state. It would either be centralized through something like a moc-generation that handles the details for each type, or through a centralized marshaller that is aware of the serialization details for each type. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Wednesday, October 22, 2014 6:17 AM Simon Hausmann wrote: On Tuesday 21. October 2014 12.56.41 Stottlemyer, Brett wrote: Again, I like the idea of remote objects working outside of Qt. Yes, protocol buffers are self-describing, but that is because there is a template. You haven't solved the problem, you've just moved it. You still need to generate the template. Something needs to know how to serialize/marshal a QTime when it sees one. And the repc compiler is the same as MOC in that sense. It just grabbed the string QTime. Right, and it relies on the existing serialization code that is spread throughout Qt to serialize various objects, the QDataStream operators. Those are great for many use-cases, especially ones where everyone is speaking Qt and everyone is using the same Qt version. This is what you're building on and supporting with QtRemoteObjects and that's fine (it works well :) Agreed. On the other hand I think it is critical for Qt's success to also support use- cases that leave our little universe (of Qt). And that means either building something yourself and convincing others to adopt it or adopt a technology/approach that already has existing mind share. For distributed objects architectures I do like the idea of supporting wire formats that have existing mind share and I also do think it is very important to make the programmers aware of the distribution. Sure. I agree in concept. But how are you suggesting we go about this? My resistance comes from several factors: 1) I think what you are proposing is what D-Bus brings to the table. By focusing on the Qt side, I think remote objects is easier to use than D-Bus, but is also not seen as competing with it. You risk both by making it more general. 2) What you are proposing is a massive increase in scope, which obviously takes a lot of time/resources to accomplish. Is Digia offering to help? 3) As stated, the existing code is spread throughout all of Qt. I assert that any new wire format support needs to be spread throughout Qt as well. Otherwise you have a maintenance nightmare trying to keep up with changes to all of the various types of objects. Unless you have a solution I'm not seeing, I think the best thing to do is try to future-proof remote objects so such a change is possible down the road. Remote procedure calls work 99% of the time and it is very tempting to hide the 1% from the developer, especially since in local development environments the network for example is always reliable. We can just throw an exception in the unlikely event of a transport layer failure or the remote process crashing. But it is this very paradigm that a local proxy object pretends to be as reliable as a real local object that - in my experience - creates unreliable systems in the long run. In my opinion a well designed system makes the programmer rather aware that remote calls can fail and that it does require dealing with. And that there's of course a latency involved in method calls. We are trying to capture these cases in an intuitive way. If you have specific suggestions, please pass them along. As it stands now, the Replica has isInitialized() and isReplicaValid() methods (and corresponding signals) to describe the object status. We recognize (and Alex Blasche pointed this out in his gerrit comments) that the error handling needs to be improved. We intend to work on that. Of course, patches/suggestions are welcome! This is clearly something where philosophies and opinions differ, so a perfect subject for a healthy debate of what we should focus on in Qt, as we try to to make software development easier. I think the discussion needs to be whether Qt will accept an alternate or additional method of marshalling data types. But I guess that is up for debate! Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Tuesday 21. October 2014 12.56.41 Stottlemyer, Brett wrote: On Tuesday, October 21, 2014 8:19 AM Simon Hausmann wrote: The QTime is literally the result of string copypaste from the token in the header file into the moc generated C++ code. There's no type lookup, resolution or analysis involved :) But that's the point, isn't it? The type itself needs to be sufficient for generating the protocol buffer. MOC is relying on the fact the Qt knows how to copy objects of type QTime, and serialize them. The code I pasted doesn't know what QTime is, but it is described in the QTime code generated when MOC runs on the QTime header. It relies on introspection being available, and generates the code necessary for introspection as it runs against the Qt codebase. Unless you expect the end user to manually write the protocol buffer, the exact same process of breaking down objects is needed for remote objects. How else can I automatically generate a protocol buffer for QTime (or any arbitrarily complex QObject)? The objects need to be self-describing, which is what MOC gives us. Again, I like the idea of remote objects working outside of Qt. Yes, protocol buffers are self-describing, but that is because there is a template. You haven't solved the problem, you've just moved it. You still need to generate the template. Something needs to know how to serialize/marshal a QTime when it sees one. And the repc compiler is the same as MOC in that sense. It just grabbed the string QTime. Right, and it relies on the existing serialization code that is spread throughout Qt to serialize various objects, the QDataStream operators. Those are great for many use-cases, especially ones where everyone is speaking Qt and everyone is using the same Qt version. This is what you're building on and supporting with QtRemoteObjects and that's fine (it works well :) On the other hand I think it is critical for Qt's success to also support use- cases that leave our little universe (of Qt). And that means either building something yourself and convincing others to adopt it or adopt a technology/approach that already has existing mind share. For distributed objects architectures I do like the idea of supporting wire formats that have existing mind share and I also do think it is very important to make the programmers aware of the distribution. Remote procedure calls work 99% of the time and it is very tempting to hide the 1% from the developer, especially since in local development environments the network for example is always reliable. We can just throw an exception in the unlikely event of a transport layer failure or the remote process crashing. But it is this very paradigm that a local proxy object pretends to be as reliable as a real local object that - in my experience - creates unreliable systems in the long run. In my opinion a well designed system makes the programmer rather aware that remote calls can fail and that it does require dealing with. And that there's of course a latency involved in method calls. This is clearly something where philosophies and opinions differ, so a perfect subject for a healthy debate of what we should focus on in Qt, as we try to to make software development easier. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Monday, October 20, 2014 6:45 AM Simon Hausmann wrote: I wasn't trying to suggest using protocol buffers as a wholesale replacement for MOC generated code. I was thinking only of the piece for marshalling Properties and Signal arguments for QueuedConnection calls, and the return value. Since the types are known at compile time (based on everything MOC already does), it should be possible to generate the protocol buffer definitions for those items, which would then be compiled with the rest of the MOC generated code. Hmm, the problem I see is that the types are _not_ known at moc execution time, only at C++ compile time. I'm not sure what you mean. The MOC output includes lines like: case 3: _t-timeChanged2((*reinterpret_cast QTime(*)(_a[1]))); break; The QTime is determined by MOC when MOC runs Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Tuesday 21. October 2014 12.14.35 Stottlemyer, Brett wrote: On Monday, October 20, 2014 6:45 AM Simon Hausmann wrote: I wasn't trying to suggest using protocol buffers as a wholesale replacement for MOC generated code. I was thinking only of the piece for marshalling Properties and Signal arguments for QueuedConnection calls, and the return value. Since the types are known at compile time (based on everything MOC already does), it should be possible to generate the protocol buffer definitions for those items, which would then be compiled with the rest of the MOC generated code. Hmm, the problem I see is that the types are _not_ known at moc execution time, only at C++ compile time. I'm not sure what you mean. The MOC output includes lines like: case 3: _t-timeChanged2((*reinterpret_cast QTime(*)(_a[1]))); break; The QTime is determined by MOC when MOC runs The QTime is literally the result of string copypaste from the token in the header file into the moc generated C++ code. There's no type lookup, resolution or analysis involved :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Monday, October 20, 2014 7:49 AM Branislav Katreniak wrote: What about removing the hard dependency of type safe replicas on the rep language and rep compiler? Can we extend moc compiler? In theory, yes. When we write the server objects, we already have the QObject with all the signals and slots visible for moc. Moc could generate the type safe replica objects based on this information. This approach enables type safe replicas for existing Qt code base. Two issues, one technical, one not. The technical issue is deciding what signals/slots/properties are forwarded. There's stuff in QObject that doesn't make sense to emit/modify on the Replica side. Not sure there is a good way to fine tune that without additional syntax for MOC, which isn't needed outside of remote objects. The non-technical issue is that I don't see changes to MOC for a playground module. Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Tuesday, October 21, 2014 8:19 AM Simon Hausmann wrote: The QTime is literally the result of string copypaste from the token in the header file into the moc generated C++ code. There's no type lookup, resolution or analysis involved :) But that's the point, isn't it? The type itself needs to be sufficient for generating the protocol buffer. MOC is relying on the fact the Qt knows how to copy objects of type QTime, and serialize them. The code I pasted doesn't know what QTime is, but it is described in the QTime code generated when MOC runs on the QTime header. It relies on introspection being available, and generates the code necessary for introspection as it runs against the Qt codebase. Unless you expect the end user to manually write the protocol buffer, the exact same process of breaking down objects is needed for remote objects. How else can I automatically generate a protocol buffer for QTime (or any arbitrarily complex QObject)? The objects need to be self-describing, which is what MOC gives us. Again, I like the idea of remote objects working outside of Qt. Yes, protocol buffers are self-describing, but that is because there is a template. You haven't solved the problem, you've just moved it. You still need to generate the template. Something needs to know how to serialize/marshal a QTime when it sees one. And the repc compiler is the same as MOC in that sense. It just grabbed the string QTime. Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Sunday 19. October 2014 18.45.57 Stottlemyer, Brett wrote: [...] 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. I agree. I mean, it shouldn't be a necessity, but it should be easy to opt-in or be part of an example or common-case RPC system that's built on top of lower level components that allow custom RPC. 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/QtypeSocket/QtypeServer 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. Ah, this may indeed be a misunderstanding. I'm not objecting against the use of Qt in the Qt side of such a system, especially as reference implementation. But the wire protocol, connection establishment and discovery shouldn't be tied to Qt IMHO but allow for other processes to be implemented using different runtimes. However it makes natural sense for libraries in Qt to maximize the use of Qt of course. 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? Yes, it's possible to boost up QDataStream, come up with a schema format, implement bindings in various languages/runtimes and try to gain mind share for it. Certainly a valid approach. Somebody has to do it though :) 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. Yes, that's indeed a rather interesting idea. The qt dbus binding allow for something similar (generate dbus xml from a Q_OBJECT header). The main issue I see is that protocol buffers first and foremost define the format of messages for serialization, while a meta object describes what you can do with an instance of an object. And I'm not suggesting the use of protobuf's socketrpc, that would be a poor match IMO. So what would a .proto file look like for a Q_OBJECT? That's not evident to me yet. However a .proto file could be written (manually) that describes the messages needed to allow calling into QObjects. Basically a schema for what QWebChannel also does. In order to allow for custom types to be passed through, the meta- type system would have to be extended to allow for registering mappings from meta-type ids to protocol buffer descriptors. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Monday, October 20, 2014 2:32 AM Simon Hausmann wrote: So what would a .proto file look like for a Q_OBJECT? That's not evident to me yet. However a .proto file could be written (manually) that describes the messages needed to allow calling into QObjects. Basically a schema for what QWebChannel also does. In order to allow for custom types to be passed through, the meta- type system would have to be extended to allow for registering mappings from meta-type ids to protocol buffer descriptors. Just have a minute, and wanted to clarify one point. I wasn't trying to suggest using protocol buffers as a wholesale replacement for MOC generated code. I was thinking only of the piece for marshalling Properties and Signal arguments for QueuedConnection calls, and the return value. Since the types are known at compile time (based on everything MOC already does), it should be possible to generate the protocol buffer definitions for those items, which would then be compiled with the rest of the MOC generated code. Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Monday 20. October 2014 10.38.26 Stottlemyer, Brett wrote: On Monday, October 20, 2014 2:32 AM Simon Hausmann wrote: So what would a .proto file look like for a Q_OBJECT? That's not evident to me yet. However a .proto file could be written (manually) that describes the messages needed to allow calling into QObjects. Basically a schema for what QWebChannel also does. In order to allow for custom types to be passed through, the meta- type system would have to be extended to allow for registering mappings from meta-type ids to protocol buffer descriptors. Just have a minute, and wanted to clarify one point. I wasn't trying to suggest using protocol buffers as a wholesale replacement for MOC generated code. I was thinking only of the piece for marshalling Properties and Signal arguments for QueuedConnection calls, and the return value. Since the types are known at compile time (based on everything MOC already does), it should be possible to generate the protocol buffer definitions for those items, which would then be compiled with the rest of the MOC generated code. Hmm, the problem I see is that the types are _not_ known at moc execution time, only at C++ compile time. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
What about removing the hard dependency of type safe replicas on the rep language and rep compiler? Can we extend moc compiler? When we write the server objects, we already have the QObject with all the signals and slots visible for moc. Moc could generate the type safe replica objects based on this information. This approach enables type safe replicas for existing Qt code base. Kind regards Brano On Fri, Oct 17, 2014 at 11:33 AM, Stottlemyer, Brett (B.S.) bstot...@ford.com wrote: On Friday 17 October 2014 11:31:10 Sumedha Widyadharma wrote: Do you think it would be possible to use run-time introspection à la QtWebChannel and dynamic signals/slots to get rid of the pre-processor? (see: http://doc.qt.digia.com/qq/qq16-dynamicqobject.html) I can't speak to QtWebChannel (trust Milian on that front), but I can speak to QtRemoteObjects. The functionality to point at has been incorporated into Qt via (private) QMetaObjectBuilder. This was a topic that was brought up at QtCS. We've incorporated the mechanism into QTRO, so you can indeed ask for an object as a Replica without using our compiler. This does have some implications. Compile time type-safety is certainly part of a decision to use compiled vs. dynamic Replicas. Second, the repc compiler enables default values for properties. So you have the ability show something reasonable, even if the source object isn't available. For dynamic objects, you don't even know what properties are available until the Replica can be initialized from the Source object. Third, usage from C++ is a bit trickier as well, but less of a concern from QML. Finally, certain types need to be registered for use with stream operators. We can do this with the compiled Replicas, but not with dynamically created ones. Those are the big hitters off the top of my head. So it really depends on the use-case whether QRemoteObjectDynamicReplica (yes, it is a mouthful - still like the old name better) is a good option over the compiled version. But the capability is already there. If you go the route of dynamic Replicas, you can use QObject-derived types as the Source, and avoid the repc compiler entirely. Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Thursday, October 16, 2014 11:14:53 AM Stottlemyer, Brett wrote: Qt Devs, I know I've been silent for a while after the discussing Replicant and QQSM at the Qt Contributors Summit. If you aren't aware, QQSM was renamed to DSM (Declarative State Machine) and has been incorporated into QML. It is already merged and will be released with Qt 5.4. The 2nd project was Replicant. As noted at QtCS, the name Replicant is already in use in software. So we have a new name: QtRemoteObjects. Not quite ahead of Dev Days, we've pushed it out to Qt's playground area. You can find it at https://qt.gitorious.org/qtplayground/qtremoteobjects. It is sparse on documentation, but that will be worked on over the coming weeks. We've made a bunch of changes since QtCS, some based on excellent suggestions from contributors, some based on internal needs. Hope you like it. The key to QtRemoteObjects, which I think differentiates it from other IPC/RPC approaches, is the idea of having a full (Qt) object in the new process. All property changes on the Source object will be reflected (with notification Signals) on the Replica object(s). Any Signals emitted from the Source will be emitted from every Replica. You can set properties on a Replica, as well as call Slots, but the implementation is such that the requests are sent to the Source, which responds to the calls. Any changes are then reflected by Signals or Property changes, as appropriate - this means that all instances (including the Source) will reflect the changes. The net result is that you can have a very complex object (talking to sensors, managing a resource, etc) in one process (or device), yet still interact with it in a Qt friendly way from another process (or device). All of the complexity of the IPC is handled internally by QtRemoteObjects. Feedback if, of course, welcome. 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). I think if we want to address this in Qt, then we should take three requirements very very seriously: 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. 2) The system must allow for versioning. Not all devices/services/processes will always be using the same version of the overall protocol. 3) The system should support a very convenient and robust mechanism to discover and connect to other processes. Based on experience with an in-house project I would suggest to avoid a wire format that is tied to Qt, i.e. QDataStream. My current favorite on this are actually google protocol buffers, because they are rather good with versioning and you can get bindings for _a lot_ of languages, including JavaScript. QDataStream on the other hand is terrible when it comes to versioning, compared to the convenience other solutions offer. Another option would be CaptnProto or Flatbuffers, but they language support is not as wide spread as protocol buffers. Either way they are rather similar in concept and I think a good fit. Regarding discovery it would be really nice to support bluetooth for peer to peer connectivity and zeroconf for regular IP based networks. We have had a very good experience using Zeroconf for this matter and it's easily available these days (including Android, iOS, Linux and even Windows) Binding just QObjects across process boundaries is tempting in the short run, but I think it would put us (Qt) on an island. I'd much rather see Qt provide the low-level enablers to allow our users to either do their own RPC _and_ provide a sample implementation for convenience (that uses futures/promises). Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
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/QtypeSocket/QtypeServer 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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
Hi, cool stuff :) Do you think it would be possible to use run-time introspection à la QtWebChannel and dynamic signals/slots to get rid of the pre-processor? (see: http://doc.qt.digia.com/qq/qq16-dynamicqobject.html) I've had ideas like that for a QtWebChannel C++ client library. Haven't tried it though. Regards, Sumedha Widyadharma -- Sumedha Widyadharma System Integrator basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel : +49 6151 870 589 128 | Fax: +49 6151 870 589 199 sumedha.widyadha...@basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschäftsführung: Dr. Eva Brucherseifer, Heike Ziegler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Friday 17 October 2014 11:31:10 Sumedha Widyadharma wrote: Hi, cool stuff :) Do you think it would be possible to use run-time introspection à la QtWebChannel and dynamic signals/slots to get rid of the pre-processor? (see: http://doc.qt.digia.com/qq/qq16-dynamicqobject.html) I've had ideas like that for a QtWebChannel C++ client library. Haven't tried it though. Qt RemoteObjects is very different from Qt WebChannel - it gives you a typesafe C++ interface. Qt WebChannel does some similar things but only constructs a dynamic JavaScript object via introspection. There is no way to use that directly from C++, esp. not in a typesafe manner. Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On 17.10.2014 11:50, Milian Wolff wrote: [...] Qt RemoteObjects is very different from Qt WebChannel - it gives you a typesafe C++ interface. Qt WebChannel does some similar things but only constructs a dynamic JavaScript object via introspection. There is no way to use that directly from C++, esp. not in a typesafe manner. [...] The idea would be to add type information to the object descriptors of QtWebChannel. At no point would the javascript library be involved in this scenario. I'm not sure if the required kinds of proxy objects can be dynamically constructed though, thus the question. It might not be possible (or a good idea) to do the same thing in both projects, but we've also already thought that sometimes having (optional) type information in QtWebChannel would be good. Regards, Sumedha Widyadharma -- Sumedha Widyadharma System Integrator basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel : +49 6151 870 589 128 | Fax: +49 6151 870 589 199 sumedha.widyadha...@basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschäftsführung: Dr. Eva Brucherseifer, Heike Ziegler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Friday 17 October 2014 12:02:12 Sumedha Widyadharma wrote: On 17.10.2014 11:50, Milian Wolff wrote: [...] Qt RemoteObjects is very different from Qt WebChannel - it gives you a typesafe C++ interface. Qt WebChannel does some similar things but only constructs a dynamic JavaScript object via introspection. There is no way to use that directly from C++, esp. not in a typesafe manner. [...] The idea would be to add type information to the object descriptors of QtWebChannel. At no point would the javascript library be involved in this scenario. I'm not sure if the required kinds of proxy objects can be dynamically constructed though, thus the question. It might not be possible (or a good idea) to do the same thing in both projects, but we've also already thought that sometimes having (optional) type information in QtWebChannel would be good. In order to have a typesafe interface, you must have a header available at compiletime. There is no way you can construct that dynamically at runtime. Adding type information to Qt WebChannel might be interesting in the long-run, but is in no way related to the Qt RemoteObjects project. While both projects are similar, in the end they solve different problems. Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Friday 17 October 2014 11:31:10 Sumedha Widyadharma wrote: Do you think it would be possible to use run-time introspection à la QtWebChannel and dynamic signals/slots to get rid of the pre-processor? (see: http://doc.qt.digia.com/qq/qq16-dynamicqobject.html) I can't speak to QtWebChannel (trust Milian on that front), but I can speak to QtRemoteObjects. The functionality to point at has been incorporated into Qt via (private) QMetaObjectBuilder. This was a topic that was brought up at QtCS. We've incorporated the mechanism into QTRO, so you can indeed ask for an object as a Replica without using our compiler. This does have some implications. Compile time type-safety is certainly part of a decision to use compiled vs. dynamic Replicas. Second, the repc compiler enables default values for properties. So you have the ability show something reasonable, even if the source object isn't available. For dynamic objects, you don't even know what properties are available until the Replica can be initialized from the Source object. Third, usage from C++ is a bit trickier as well, but less of a concern from QML. Finally, certain types need to be registered for use with stream operators. We can do this with the compiled Replicas, but not with dynamically created ones. Those are the big hitters off the top of my head. So it really depends on the use-case whether QRemoteObjectDynamicReplica (yes, it is a mouthful - still like the old name better) is a good option over the compiled version. But the capability is already there. If you go the route of dynamic Replicas, you can use QObject-derived types as the Source, and avoid the repc compiler entirely. Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
