Since you're looking at "everything is a message", consider how microkernels like sel4[1] and QNX[2] do system calls as message passing.

[1] https://docs.sel4.systems/ApiDoc.html [2] http://www.qnx.com/developers/docs/6.4.1/neutrino/getting_st...

>Dagger is WAY TOO MINIMAL

It is not necessarily too minimal. I'll echo what someone said in another comment and suggest you look deeply at Plan 9. For example, look at the Plan 9 networking API. That will give you some insight on how you can express complicated interactions using only the interface you have already described for Dagger.

Picking just the most fun aspect to reply to, because this is too long already :)

> would this look? I'm interested by what you mean by this

One area UNIX fails at is a single global flat system interface, it makes evolutionary change difficult without introducing permanent "variant" system calls (e.g. openat()) that must be supported in tandem with the original interface, in addition to an automatic penalty for any innovation that might wish to add more, because it must be supported forever.

To skirt around this, one popular option in UNIX land is instead not to define any interface: just dump whatever magic is required into some ioctl() and claim it is device-specific, and so we end up with what an interface that isn't quite guaranteed and definitely unofficial, but that's okay because it's driver-specific, but then a second driver comes along and adds a similar interface, and now we have 2 options for frobbing a particular device, with no obviously correct choice, and no guarantee frobbing will be supported that way forever. In other words, we got the worst of both worlds by trying to ignore impermanence.

(Just a side note, a real-life example of those ioctls might be e.g. how Linux used to support asking the filesystem driver for a mapping of unused sectors, or how you set or query the FAT filesystem's DOS filesystem label)

UNIX exports APIs for all of this, and it's mostly frozen in stone forever:

- Rewinding tape drives

- Configuring start/stop bits of serial lines

- Filesystem operations with fixed semantics designed around a local storage device, with uid/gid/mode security, and with extended attributes and ACLs bolted on the side

- Multiple variants of file locking schemes that are all perfectly useless in multithreaded apps

- A security model that's baked in at the API level (e.g. chown()).

Just taking the silly 'rewinding tapes' example, planning an API for permanent compatibility with a problem space that 99.9% of people no longer have, rising to 100% at some point eventually, it's easy in hindsight to see this interface should be modularized somehow, and preferably made entirely optional.

How that modularity looks is definitely up for debate.. looking at Windows for one approach, in COM (and ignoring its baroque useability!) handles export only one interface (IUnknown) whose sole method allows enumerating the contracts the handle (object) supports. For example here is DirectShow: https://docs.microsoft.com/en-us/windows/desktop/directshow/... , see how a single input can implement IDvdControl, IAMTVTuner, both, or neither, and if neither are implemented, the handle is still useable via IPin and related interfaces that actually control how data flows from the input.

Mapping that to UNIX, a handle might have protocols like IUnixSecurity, ITapeOperations, IBraindeadLocking, ILinuxSpecificLocking, IStream, all or none etc., where a handle has no guaranteed fixed vocabularity perhaps except for the most fundamental expected anywhere that handle is found (in the case of a file, perhaps that is IStream).

By exporting the impermanence down to consumer code, accessing any particular interface becomes an explicit affair, because you must always request it upfront. You can still implement a media player program by wiring up some filter graph using a handle you received from someplace else, but disable the rewind and eject buttons if querying those interfaces failed -- this is literally how some stuff works on Windows:

    handle = ask_user_for_media_input()
    wire_up_graph(handle)
    if(supported(handle, "dvd player")) {
        enable_eject_button();
    }

Meanwhile at the top of the stack, outside of absolutely having to support some core interfaces that can never go away, the cost of adding and retiring sundry features is reduced, as the reality of permanence that has always existed has been pushed down the stack, where end users can choose to accept or ignore it.

---

An ideal interface might resemble a predefined root handle or sentinel value with the ability to construct new handles bound to some protocol. Imagine a language like (but not quite) protocolbuffer services, where those read/write/open/close/sync calls were methods of a particular named interface. The IDL would output wrappers to speak it. Probably already you can see room for splitting 'sync' out into some kind of IBufferedStream optional interface.

Maybe like:

    #include <os.h>                             // Invoke(handle, char *interface, void *in, void *out) -> bool
                                                // Close(handle) -> void
    #include <os/interface.h>                   // GetInterface(handle, char *interface) -> void *
                                                // Require(handle, char *interface) -> void *
    #include <os/services/console.h>            // IF_CONSOLE, Console, Console_write
    #include <os/services/filesystem.h>         // IF_FILESYSTEM, Filesystem, Filesystem_open, Filesystem_error
    #include <os/services/stream.h>             // IF_STREAM, Stream_read, Stream_write
    #include <os/services/buffered_stream.h>    // IF_BUFFERED_STREAM, BufferedStream_sync

    int main(void)
    {
        Filesystem fs = Require(NULL, IF_FILESYSTEM);
        Console console = Require(NULL, IF_CONSOLE);

        File *fp;
        if((fp = Filesystem_open(fs, "/etc/passwd", O_RDWR)) == NULL) {
            Console_write(console, "open failed: %s", Filesystem_error(fs));
            return 1;
        }

        if(File_write(fp, "foo\n") == -1) {
            Console_write(console, "write failed: %s", Filesystem_error(fs));
            return 1;
        }

        // Optional. Underlying Invoke() will fail if interface absent.
        BufferedStream_sync((BufferedStream) fp);

        return 0;
    }

A real killer would be other than simplifying that calling style, somehow unifying it with the calling convention for linked modules, so by replacing a handle you could direct an OS-level protocol to a library, or perhaps better, the act of calling an OS service caused an optional library to be loaded and bound to the handle you were returned, say in the case of an ancient ITapeDrive interface that's long since stopped being a once-upon-a-time core feature.

But the main point from the example is probably the notion of an OS with only two core interfaces - Invoke() and Close()

Another place you could look for inspiration of this sort is Objective C -- a similar concept is built into its guts, and its dynamic dispatch msgsend() function is optimized to all hell to match!

Another source of inspiration is the 1985 spec for AmigaOS IFF, http://wiki.amigaos.net/wiki/EA_IFF_85_Standard_for_Intercha...

> Customers should be able to move their own data between independently developed software products. And they should be able to buy data libraries usable across many such products. The types of data objects to exchange are open-ended and include plain and formatted text, raster and structured graphics, fonts, music, sound effects, musical instrument descriptions, and animation ... The IFF philosophy: “A little behind-the-scenes conversion when programs read and write files is far better than N x M explicit conversion utilities for highly specialized formats”.