> > 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
