Þ   briarpig  » wyv


The Plan9 operating system is really the topic of this page. So I could just say, "Google for Plan9 and see what it's about." And then I could say you should think about applying those ideas to designing server internals. But that doesn't even hint what might be interesting. So much of the rest of this page supplies context to suggest why the "everything is a file" model is in some way related to a similar idea: everything can be named with a file path.

trees

     Web sites typically use a tree structured namespace of URLs that look like a file system. If you ignore trailing query parameters (and many other options for complexity), the name of each page often looks like a file path. Sometimes this is actually the case: parts of a file system might hold content shown as a site by a web server. It's easy to make static sites with an isomorphic image in a file system.

     From a browsing user's point of view, there's no way to tell whether a backend is static or dynamic — whether a file system represents content, or something else (say a database) with content either persistent in secondary storage or not. You might say the point of HTTP is that you cannot tell, so actual representations might be anything. Protocols and naming schemes are just unifying devices that allow you to map anything to browsable content.

virtual

     You can think of HTTP as a kind of virtual network file system interface, if you squint and ignore incidental details. So just stick with that word virtual, because HTTP doesn't become more concrete and fixed because you think some particular web server is the canonical implementation whose internals are reality we all have to ratify.

files

     Plan9 pursued a very appealing uniform model — an extension of the original Unix view — that everything is a file. So services were described by file paths, and customizing an environment involved mounting different alternatives at appropriate file paths. In other words, it was yet another application of lexical scoping in name systems.

firstclass

     The uniformity of the naming model made it easy for the Plan9 OS to treat things as equals with basic file system entities, because all additions also looked like files. They were files as far as the OS was concerned. But this benefit was less about being files, and more about elevation to the same first class status as files. The key is first class.

paths

     Instead of files, you can make their names first class: paths naming files. (This is almost tautological, it's such a dual.) Any server like an HTTP server — a virtual file system — could put streams named with paths in first place, and map everything else to suit.

menu

     Choose one of these demos for sample code and related docs, developed together to motivate þ C++ code for this purpose.


     mu: toy, peg, imm, tag, box, symbol, token, number, bigint, class, method, reader, writer, eval, env, vm, gc, world, pcode, compiler, asm, lathe, lisp, smalltalk, design, weight, jar, card, harp, debug, profile

     thorn: todo, names, iovec, assert, log, run, hex, crc, buf, in, out, quote, escape, compare, file, deck, cow, arc, blob, tree, slice, rand, time, stat, heap, node, primes, page, book, pile, stack, atomic, lock, mutex, thread, map, meter, list, iter, ctype


Web servers are just one kind of server, but a you can easily apply a tree-structured content namespace to any server. Content in any server can be exposed by HTTP using some mapping of content to one or more URL namespace systems. So this page isn't specifically about HTTP really, since any server could have an alternative HTTP interface in addition to other ones. So it's just an example.

     There's nothing magic about HTTP per se. It's just that URL paths are far more expressive than needed to name whatever you want. So I'm asking you to apply that same expressive namespace to any server, not just web servers, because there's no reason not to do so.

linux

     Several ideas from Plan9 have been incorporated into Linux. For example, the proc file system in Linux is loosely modeled on a Plan9-ish scheme to reflect (kernel) system state in the file system. Not only can you read useful info there, you can also write new values into the proc file system to alter system behavior.

experimentation

     When I get around to attempting namespace mechanisms naming content with file paths, I don't have a specific plan in mind guiding future play. I'll just make stuff up (fun technology can be created that way), then tweak until I like how things works. Some experiments can mimic aspects of the proc file system, so server state can be observed and changed from part of the URL tree.

codename

     The codename wyv comes from the name of a character I dreamed up a few years ago as a bit of revisionist Norse mythology. (In other words, an explanation of this particular Norse god is best done with you pretending the myth is old, rather than recently made, as if Wyv is widely known as a minor Norse god. My last website was named after him.) High level app experiments with file paths and server control might use this codename.

rules

     Some parts of a server content tree can be defined declaratively as a function of other parts of the content tree, so dependent material gets generated on demand based on rules, with suitable caching (and cache invalidation) to keep things in sync without constant regeneration.

versioning

     System versioning and debugging can be achieved by editing file paths to select which of alternative versions are currently in force. This allows easy temporary disabling of content by reverting to old versions through path editing alone. And developers could preview and stage new content releases in fully deployed contexts — but visible to developers alone — solely through path editing.