Hi Brad, Am 17.06.2016 22:24 schrieb "Brad King" <brad.k...@kitware.com>: > > 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
