[VikingCoder]

If you're writing a C++ application, it can be quite useful. I've shared this before:

I worked at a company once that had a really decent HTTP server library... That they put in every program.

You'd launch an app, and to debug it, you'd access http://localhost:9001. From there, you could go to URLs for different libraries in the app. Like, if you had a compression library, you could go http://localhost:9001/compression. It would show stats about the recent work it had done, how long it took, how much CPU, RAM, disk it used. The state of variables now, etc. You could click a button to get it to dump its cache, etc.

If you were running a service on a remote machine, accessing it over HTTP to control it was just awesome. http://r2d2:9001/restart. http://r2d2:9001/quit. http://r2d2:9001/logfile.

Oh, and the services running on that remote machine would register with a system-level monitor. So, if you went to http://r2d2/services, you could see a list of links to connect to all of the running services.

...and every service registered with a global monitor for that service. So, if you knew a Potato process was running somewhere, but you weren't sure which machine it was on, you could find it by going to http://globalmonitor/Potato, and you'd see a list of machines it was running on.

Just all kinds of awesomeness were possible. Can not recommend enough.

And, I mean like, programs with a GUI. Like, picture a game. Except on my second monitor, I had Chrome open, talking to the game's engine. I could use things like WebSockets to stream data to the browser. Like, every time the game engine rendered a shot, I could update it (VNC-style) in the browser window. Except annotated with stats, etc. It was just the most useful way to organize different debug information.

And what was great was that writing a library, and wanting to output information, you wouldn't write it to std out... You'd make HTML content, and write to it. Want to update it? Clear the buffer and write to it again. As a user, if you ever want to read the buffer, you just browse it. Want to update it? Refresh the window. Or better yet, stream it over a websocket. Like Std Out on steroids. If you need to combine the output from a few libraries in a new window, you just write a bit more HTML in your code, and you're doin' it.

It's just another example, in my mind, of the power of libraries. We all get used to thinking of frameworks (IIS, Apache) as the only way to solve a problem, that we forget to even think about putting things together in new and unexpected ways. HTTP as a library - HELL YES.

Using HTML to debug programs, live, is highly under-utilized.

[CyberDildonics]

I would say that debugging a program live is highly underrated. There is no inherent reason why building a webserver into everything and using html for visualization is the best way to go. Shared memory can be used and be 100-1000 times faster, which can make a huge difference if you want to visualize large amounts of data like point clouds, pixels, etc. as they change.

In your scenario it sounds like an easy way to make a big step forward, though I don't think that takes it far enough.

[VikingCoder]

Well, for one thing, you're presuming the person who wants to inspect something a) has a debugger, b) knows how to use it, c) that the machine running the application allows access through those ports.

[CyberDildonics]

I didn't presume any of those things and I'm not sure where any of those ideas come from. A program can write to shared memory that is read by a separate program. That doesn't take a debugger and it doesn't take 'ports'. I'm actually not sure what you mean by ports.

[VikingCoder]

Sorry, I feel like we're really mis-communicating.

I proposed an idea, and you proceeded to tell me "There is no inherent reason why [my idea] is the best way to go." I think that's a pretty rough way to respond to someone suggesting an idea that might be useful under some circumstances. It's a possibly new tool in your tool-belt. I didn't mean to suggest that a hammer "is the best way to go" for any job. But sometimes the problem is a nail, and a hammer is the best tool.

You highlighted the value of "debugging a program live," which is true, but I thought you meant using a sophisticated debugger (gdb / Visual Studio, etc). For instance, Microsoft Visual Studio has (or used to have) the ability to have plug-ins to help you visualize complex structures in memory of the running process, for instance showing a Bitmap as an actual image on your screen. I thought that's what you meant, or just using gdb or some other sophisticated debugger. But yes, that was my misunderstanding.

Shared memory is nice, and I've used it before, but it required me to store all of my interesting objects in shared memory structures. Which meant changing how my application was written. Yes, sometimes I could see that being amazing. Or I suppose you make a large copy of them.

I've also done the trick where, if I hit a URL on my app, then it took the point clouds, pixels, etc, and provided a rendered PNG image of them. But it could do it without requiring me to restructure my program's memory layout (other than a few multi-threading locks, when needed.) And I've done that over WebSockets, with interactive rendering rates, basically like a VNC. And what was nice about that, again, was that I could run a process on one machine, and debug it (through HTML) from another. And grant that ability to other users, without having to tell them how to install a debugger app, and giving that app access to connect over the network, and etc.

The ports thing was in reference to the ability of Microsoft Visual Studio (and presumably other debuggers) to do remote debugging, attaching themselves to a process running on another computer. So, you have to be able to connect to that process. Whereas my proposal could work on normal HTTP / HTTPS ports, and with authentication, could enable a user to access debug views.

Anyway, yes, I very much agree with you that debugging a program live is highly underrated, and I think it's good if people share different ways to do that.

[rramadass]

Very neat! So every "public" API had a corresponding URL which could be publicly accessed over HTTP ?. Sounds like a HTTP-based overlay network within the domain of your application(s).