It is difficult to talk about this absent context - mostly, it is hard for me to frame it, because I've always thought of this as some small part of something larger. Recently I wrote a blog post that made it clear to me that this really is just a side topic that might well be better served in a general discussion of OS improvements. That post was also inspired, at least in partly, by this discussion of an IPC mechanism.
My topic today, broadly speaking, is about runtime-linked libraries, and how they are used to interact with services and devices... for a very broad definition of devices.
Suppose, just as a starting point for this conversation, that we added something to the act of loading such a library - a configuration step, if you will. In the process of loading a “configured” library, the library attempts to connect to a device or service, specified in the configuration - at least to confirm that it exists, but the point is, the configured library shall not be understood as a generic, to be used with any other device or service. This configured library shall be stored as a file, separate from the library before configuration, and the runtime linker shall understand how to use these configured libraries.
What this does, effectively, is permanently move the concept of “communicating with a specific device/service” to “loading a specific library”, or if you prefer, the concept becomes “sending a specific filepath/text string representing the library plus device/service to the program at load time”.
This implementation has some problems. On an operating system level, you are obliged to understand the concept of a generic, unconfigured library and how a configured library is a version of that generic; the application data will claim to require a configured instance of some library, and the OS needs to know what that means. This is complicated, and might arguably be a step back.
Instead of using that implementation, here's a second change: Tag every library (generic and configured) with API interface identifiers, which the library claims to support. If necessary, once the library is configured to point to a device or service, amend the tags so that they do not promise a capability that the device or service cannot provide. Change the application data so that, instead of listing specific libraries it wishes to load, it lists API keys that the program requires an implementation of. If the same API key is used in more than one place (which are logically distinct from one another), it is listed more than once, with additional options as necessary, etc.
Now, let's think for a minute about what we have.
Your application was already programmed against some API - in header files or other includes, for a standard, compiled, linkable application. The API promises you that certain functions shall be implemented in a library, whether statically linked or dynamically/runtime linked. That is, realistically, all your program cares about - once the program is compiled, when you try to call a function, something must be there. The rest… well, it's down to specifics whether things work or become a disaster.
If you could describe an entire class of devices or services with a very simple API (eg, character device or block device, streams or files), you could theoretically configure this library to link to any device of that class. Additionally… if the program requires a very simple API, there many be many libraries which provide that API, and each may behave differently. It's fair to see that as a bad thing, or at least a neutral thing, for security and stability reasons.
But with this change, suddenly the application's behavior can be customized by linking it to a different library, not merely a different device.
Suppose we have some pretend API which is designed to blink an LED; it only specifies the functions “start blinking” and “stop blinking”. A demo application loads a configured library tagged with this API, starts it, waits thirty seconds, and then stops and quits. You develop a whole bunch of different algorithms to make the LED blink in different patterns, and put each in a different, API-compatible library. Then you write a script that randomly selects an library and an LED attached to the system (assume there are many), configures the library for the LED, and sends that to the program. Each time the script loops, a different LED blinks in a different pattern for 30 seconds.
After that example, it's easy to suggest that this extension means little, but let's try a different example. The API sorts the contents of a file (let's say, not in place); the “device” is any multiline textfile. Each library implements a different sorting methodology; the example program just loads the library, sorts the file, outputs it, and quits. This is… different, conceptually, from writing a program that has a static list of sorting algorithms for you to use on a file. It's also different, conceptually, from depending on a specific library to have a static list of sorting algorithms.
It is… and I swear I did not create the mechanism specifically to line up with the name, nor did I even work hard on naming it, but the act of linking to a configured library turns the application into a Mad Lib. You give it a verb and a noun, and you get a sentence in return. Nor is it pure chaos - you constrain what kind of verbs and what kind of nouns go into the sentence at the time the sentence is created, so that the sentence always follows a particular pattern, even if the sentences are very different.
Now, here's a third step, specifically to assist in that last thing I said. Suppose that all devices (including files, services, running applications, and others) are given one or more typepaths that describe its position(s) in a relational, branching tree. So, for instance, a JSON file might be “file/text/json”. Let libraries specify any node in this tree as compatible, with the understanding that all child nodes of that branch are understood to also be compatible - if your library accepts text devices, then it accepts JSON, but it may also accept text streams from a serial port. If your library accepts any file, then it accepts all text files, all binary files, all streams, and so on.
Now, when you try to configure a library to work with a device, we can do a test - even before opening the file - to determine whether or not the library should work correctly when opened. Suddenly, the player who is doing Mad Libs with your library cannot put in a noun that doesn't work with the verb, or put differently, cannot put in a verb that doesn't work with the noun. But as long as the verb should work with the noun, they are allowed to attempt it by running the application.
And that's it, or at least, that's enough. I could ramble on about what I think happens after, but I'd like to hear what you think. To reiterate, here are the three steps (in a different order):
- All devices (including all files) are assigned one or more types (each type being a node in a relational tree, where all children are members of their parent type)
- Libraries get configured to work with a device, with a requirement specified as a device type, and are assigned one or more API keys.
- Applications that want to link to a library have the requirement specified as an API key.