> >From a 10000 feet Qt as a product point of view, it's not evident why this > >API > belongs into a separate module instead of simply into the Qt network module.
That's a historical reason and Qt's inability to accept such a contribution at the time when such changes were needed. This doesn't mean those reasons weren't valid at the time. In some cases it is desirable to have QML interfaces for those classes and when you move those classes into qtbase the dependencies are not correct. I guess one could add them to qtdeclarative as well. After all the same has happened for other qtbase classes too. On the positive side there are quite a few cases in more recent Qt history where such moves did happen. The QStorageInfo is an excellent example. The QtSystemInfo class with the same name is pretty much obsolete now. As more such moves happen I am sure that the content in QSystemInfo diminishes further. I would encourage Lorn to consider a merge the network related QNetworkInfo API's into QtNetwork. > In regards to the publish/subscribe and serviceframework bits, I wonder what > the plan is with those. How much overlap between them and Replicant is there? Potentially there is a significant overlap. The principle is the same and no there are no immediate plans for them. It's no different than the jsondb repo except that the principle applications are probably somewhat more in demand than jsondb. I wish a day had more than 24hrs .... -- Alex _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
