I'm not sure whether I should be discussing this here or on GitHub.

I have extended the existing server branch to include an internal HTTP/WebSocket server. I've used the existing Server class in build_system.py as the base class for the HTTP handler in server.py. As of right now, the only method needing to be implemented by subclasses is handle_data() which takes in the raw data and determines what to do with it. In the case of the BuildHttpHandler, it assumes the data is pure JSON and parses it before it hands it off to other methods to use it.

In order to test it out, run "b2 --python --http-server ../path/to/boostbuild/server/client/index.html " in some project.

The HttpServer class will fire up a server on port 8000 and serve the index file passed on the command line. Visit http://localhost:8000 in a browser. It is expected for the index file to create a new Websocket() connection to localhost on the same port. The server will then capture the request and return the websocket handshake. I had a test file that allowed me to manually write to the socket (via the browser's JS console) which worked quite well, but I seemed to have misplaced that example project. I then tried to connect up to Vladimir's existing React example, but there were a couple of JS problems and I don't know enough about React in order to quickly diagnose. The page loads just fine, but clicking on any of the UI buttons produces problems.

At my job, I created a dependency graph viewer utilizing D3.js and a JSON dump (a feature I have added on a company branch) from Boost.Build. It allows the user to be able to visualize the Jamfiles and the Main targets and alternatives contained within them as well as a visualization of the -d+12 output. After dreaming a little bit, I could see using the HTTP/Socket server to allow the same type of application to make requests to the build system in order to retrieve information as well as submit build requests simply by selecting a main target, choosing properties for the build request (with typeahead support) and then clicking build. A lot of the developers at my place of employment are heavy IDE/GUI users and aren't CLI savvy; this kind of tool would help them out.

I plan on performing more work on the server branch soon so that I can try and add file watching and borrow some of the engine changes from the daemon branch. I'd like to try and solidify the Builder and Server classes to provide an abstract interface.

My changes are currently on my fork of the repo and can be found on the features/http-server branch.
Let me know if what I've done sounds good or not.

Thanks,
Aaron