Introspection via pseudo-objects

Tuesday 23 May 2006This is 17 years old. Be careful.

I’ve noticed a pattern in software systems: secondary channels into the guts of the software are implemented as fake objects from the primary channel. That’s a horrible sentence; let me demonstrate with a few examples:

  • In Linux, you can find out about the current status of much of the operating system by reading pseudo-files in the /proc pseudo-filesystem.
  • In many database systems, you can find out about the dynamic status or static structure of the database by querying pseudo tables, such as MySQL’s INFORMATION_SCHEMA database.
  • Printers have self-tests that result in a page being printed containing statistics and configuration of the printer.

I know in my own work, I often have need to create a way to get into the internals of the software, either to change configuration or to get debugging or administrative information out. If the product is in the business of serving information (such as a web application), it’s straightforward to add a URL which serves the information desired.

With dynamic web applications (the word dynamic is an oxymoron at this point!), there’s practically no cost to adding another URL running another piece of code. It’s almost not even worth noting that we can create URLs to serve not just our customers, but ourselves.

I’m wondering what other more exotic examples there are out there of machines producing pseudo-products as a way of communicating with the outside world? What’s the most creative use of this technique?


The system I'm working on consists of several central servers and many remote kiosks. It uses heartbeat messages to determine the end-to-end status of the system - server, communications and kiosks. The heartbeat messages are "fake" versions of real messages and are therefore passed along the same channels and handled in largely the same way as real messages.
I see "introspection via pseudo-objects" as a different way of saying, "use what you got". That is, a company which makes printers is more likely to print configuration than tack on an LCD or web server, because x% of it "comes for free" (i.e. is already built).

For example, while working on my latest webapp (using Python's CherryPy framework), I needed a way to inspect running code. The "obvious" solution was to make a web-based Python read-eval-print loop (; since I already had the framework running, it was an easy choice to leverage it. Not always the best choice, mind you, but the easiest.
Kind of related, in lots of WSGI middleware (web app filters, basically) I take over some piece of the URL space (e.g., /_debug) and pass everything else through. Since the code doesn't have a life of its own -- it's not itself a web app -- it's really borrowing a piece of the parent (child?) web app's space.

I'm not sure if that's the same idea or different from fake objects. It's like how GNU Screen captures certain extended terminal escape codes, while letting other codes bubble up to the actual terminal.

Other techniques might be things like a dictionary/associative-array-like objects, that watch how they are accessed. Which is kind of a decoration pattern.
The examples that you listed are all a matter of taking over some portion of a namespace to do something "out of band" -- print a page of diagnostics, examine process memory, etc. Cool stuff. A similar idea is to implement an existing protocol (HTTP / FTP) to allow inspection. Lots of devices: routers, firewalls, printers, etc. go this route. That said, capabilities like these make security folks nervous. How protected are these inspection mechanisms from hackers? They need to be tested for security issues as vigorously (or more so) than the usual channels into your application or device.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.