Hi Stephen, I will then continue down that road.
Next steps are a way to consistently report progress as well as being able to have several protocol versions at the same time and have a client pick one. I will just put them atop my current branch, as that is going to need basically the same amount of retro-active integration into similar places as the current changes. I am not keen on doing that twice:-) Best Regards, Tobias On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly <steve...@gmail.com> wrote: > Stephen Kelly wrote: > >> Tamás Kenéz wrote: >> >>> That's great and really does open a new world for IDEs! >> >> Thanks! Let's see if the interest grows. >> >> I've just pushed the daemon code here: >> >> https://github.com/steveire/cmake/tree/cmake-daemon > > Tobias made a pull request there. Rather than review it there, I will review > it here for visibility. > > https://github.com/steveire/CMake/pull/2 > > The branch is quite it hard to review, or even to see the particular > changes, due to large commits and diff noise. If the Daemon reaches a level > of completeness that it could be upstreamed (See > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740 > > ) then these commits (including all of my commits on the branch) would have > to be rewritten, split, made reviewable etc making heavy use of `rebase -i`. > > In a way, we don't have to do that now, but I'm also not very enthusiastic > about making the `cmake-daemon` branch commits unreadable. I would add your > commits to the branch if they we split and in the appropriate place (eg, > with the cmServerProtocol0_1 change early in the cmake-daemon branch). > > The changes in your branch are good and useful to more than just QtCreator. > > Things that I like in your branch: > > * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type > and cookie consistency. > * Returning cmServerResponse objects from the cmServerProtocol instead of > invoking the server from the cmServerProtocol. > * A way to version the protocol in a future-proof way with C++ classes. > * Implementation of daemon and protocol error messaging infrastructure. > (Reporting errors from cmake code requires other refactoring: > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636) > > So I think that is progress! > > Thanks, > > Steve. > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers