Re: [cmake-developers] daemon-mode: Infrastructure
On Tue, Jun 14, 2016 at 02:00:14 +0200, Tobias Hunger wrote:
> Implementing new Protocol Versions:
> ==
> Deprecating old Protocol Versions:
>
One idea that came up on a previous project was the following:
namespace protocol {
namespace aspect1 {
namespace v1 {
}
namespace v2 {
}
}
namespace aspect2 {
namespace v1 {
}
}
namespace v1 {
namespace aspect1 = aspect1::v1;
namespace aspect2 = aspect1::v1;
Version version(1, 0);
bool deprecated = true;
}
namespace v2 {
namespace aspect1 = aspect1::v2;
namespace aspect2 = aspect1::v1;
Version version(2, 0);
bool deprecated = false;
}
namespace latest = v2;
}
Then the code can use `protocol::v1::aspect1::` for explicit v1
communication and `protocol::latest::` in any normal code. It does
require C++11 though. There's probably some template metaprogramming
magic that could be done to instantiate communication ends for each
protocol namespace once communication is done.
I have no idea how maintainable in the long-term this is though.
--Ben
--
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
Re: [cmake-developers] daemon-mode: Infrastructure
Hi Brad, Am 17.06.2016 22:24 schrieb "Brad King" : > > On 06/13/2016 08:00 PM, Tobias Hunger wrote: > > * There will always be 1 client talking to a server. > > * Client/Server communicate using JSON messages > > Yes. IIRC it is using stdin/stdout (I haven't checked the code), > so limiting to one client is implicit. True. Still it does not hurt to state explicitly, especially considering that I think of the stdin/out as an implementation detail. There is no reason for the code not to switch to pipes or sockets for communication. > In this case, is it actually a daemon? It is not expected to outlive > the client that started it. Perhaps we should consider a different name. I am bad at names:-) Plus Stephen made quite a bit of PR for the CMake daemon idea. > One possible problem with using stdin/stdout is that when CMake runs the > configuration the project code can do things like execute_process that > may share the stdout with the child process. That may allow the child > process to print content formatted to look like the protocol and trick > the client. Ideally all output handling would avoid printing things to > stdout in server/daemon mode, but that may take some effort to achieve. Yes, unexpected output on stdout could cause havok to the parser. So far this worked well though, and the magic string before/after messages prevented any unexpected interactions. > > What do you think? Does this make sense? > > It sounds fine to me. I'll state the caveat that I've had little experience > in maintaining versioned protocols like this though. Hopefully others can > review this too. Yes, I hope other IDE developers will chime in at some point... > On 06/14/2016 04:30 AM, Tobias Hunger wrote: > > I think it would make perfect sense to ship the first cmake version with > > included daemon-mode with a big, fat warning that the interfaces are not > > finalized yet and will change in incompatible ways during the first release > > cycle (or maybe two:-). > > Yes. Should we make the option to activate it different, and include > "experimental" in its name? I think the idea is that no clients should > be released that depend on the experimental behavior in CMake. I now added a patch that allows protocol versions to be marked as experimental. These are only visible to clients that started "cmake -E daemon --experimental". The only existing protocol version is now marked experimental. I think that makes it pretty clear what is experimental and what is not and clients do not need to change (except for maybe dropping the --experimental flag) to go to a stable interface once we are satisfied with the first version. Best Regards, Tobias -- 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
Re: [cmake-developers] daemon-mode: Infrastructure
On 06/13/2016 08:00 PM, Tobias Hunger wrote: > * There will always be 1 client talking to a server. > * Client/Server communicate using JSON messages Yes. IIRC it is using stdin/stdout (I haven't checked the code), so limiting to one client is implicit. In this case, is it actually a daemon? It is not expected to outlive the client that started it. Perhaps we should consider a different name. One possible problem with using stdin/stdout is that when CMake runs the configuration the project code can do things like execute_process that may share the stdout with the child process. That may allow the child process to print content formatted to look like the protocol and trick the client. Ideally all output handling would avoid printing things to stdout in server/daemon mode, but that may take some effort to achieve. > What do you think? Does this make sense? It sounds fine to me. I'll state the caveat that I've had little experience in maintaining versioned protocols like this though. Hopefully others can review this too. On 06/14/2016 04:30 AM, Tobias Hunger wrote: > I think it would make perfect sense to ship the first cmake version with > included daemon-mode with a big, fat warning that the interfaces are not > finalized yet and will change in incompatible ways during the first release > cycle (or maybe two:-). Yes. Should we make the option to activate it different, and include "experimental" in its name? I think the idea is that no clients should be released that depend on the experimental behavior in CMake. Thanks, -Brad -- 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
Re: [cmake-developers] daemon-mode: Infrastructure
PS: I think it would make perfect sense to ship the first cmake version with included daemon-mode with a big, fat warning that the interfaces are not finalized yet and will change in incompatible ways during the first release cycle (or maybe two:-). In my experience you only get the full feedback once the first release is out and users can test it without building the code themselves. So this would provide an opportunity to battle-harden all the daemon-mode APIs without commiting us too early. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- 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
[cmake-developers] daemon-mode: Infrastructure
Hello, one important piece of feedback from the daemon-mode: Project structure discussion is that we need a policy to remove old code again. So I thought I should write up a bit about the infrastructure and versioning support of the daemon-mode branch I am working on. Basic Assumptions: = These are kind of hardcoded into the implementation and hard to change: * There will always be 1 client talking to a server. * Client/Server communicate using JSON messages Implementation Overview: == Basically "daemon-mode" is implemented in the cmServer class. That class uses libuv to receive requests from a client application and to react on those requests. There is nothing that stops the cmServer from also signalling the client about state changes (e.g. CMakeLists.txt files being changed on disc), but that is not implemented at this time. In the constructor of cmServer you can define an arbitrary number of cmProtocolVersion objects, each with a different version number (major/minor numbers). On first connect the cmServer will present the list of supported protocol versions to the client and the client has to pick one of the supported versions. The server will call Activate() (do your initialization here;-) on the cmProtocolVersion object with the selected version number. >From that point on the cmProtocolVersion object is responsible for all further interactions with the client. The cmServer will turn all incoming messages into cmServerRequest objects and pass those to the selected cmProtocolVersion's Process(...) method. This method will return a cmServerResponse object (which can be created from the cmServerRequest), which the cmServer will send on to the client. Proposed Versioning: === The protocol version should start at version 1.0. Any time new functionality is made available to daemon-mode, the minor version number will be incremented. This includes new commands becoming available as well as existing commands returning new keys in addition to sending all the old keys. Any time a incompatible change (e.g. removal of functionality, restructuring of responses to requests, etc.) is made, the major version is incremented and the minor is reset to 0. This includes removing existing commands or changing the semantics/return types of keys returned in response to any existing command. If there was already a matching version bump, then there is no need to do another till after the next release of cmake made. So two new functionalities in one development cycle: Still only increase the minor number by one. Requesting Protocol Versions: = Let's assume we are writing a client for cmake-daemon as shipped in cmake 4.2.4. At that time in the future the protocol version for the cmake-daemon is at version 1.4 and that is what we test our application with. Our client should then request daemon mode to use protocol version 1.4 if available. If that is not available, then it should just request the highest minor number for version 1 and use that. That *should* be compatible with version 1.4. If there is no more protocol version 1.x supported the client should abort or at least warn and continue with a higher major version number. Implementing new Protocol Versions: == * minor version bumps: Add a new cmServerProtocol class. Have its Process(...) method implement the new functionality and then forward to an instance of the previous version. The sloppy approach would be to implement the the new functionality in the previous versions class and just bump its number:-) * major version bumps: At that point I would copy the existing code of the previous version into a new cmServerProtocol class and then clean it up. Then implement the changes in the new class. Deprecating old Protocol Versions: I would remove all the code for one major protocol version in one go. That should be fairly straight forward to do (and the reason why I suggested to just copy the code into a new major version of the protocol) and should have little potential for damage. In general I would suggest keeping old major versions around for at least three cmake releases, but I would not put hard rules here: If some old major version does not cost maintenance, then I'd suggest keeping it longer. On the other hand, if some changes require a major cmake version bump (e.g. changing the cmake language in incompatible ways, etc.) so that major user interaction is required during an update, then I would also dump all old protocol versions immediately. Such fundamental changes will probably also reflect deeply in the cmake internal structure, which will also reflect in the daemon-mode protocol. I do not think it makes sense to invest heavily into compatibility to old daemon-mode clients in such an event. What do you think? Does this make sense? Best Regards, Tobias -- Powered by www.kitware.com Please keep me
