[FoRK] HTTP 0.2, 9p, and op
jbone at place.org
Fri Dec 25 08:18:21 PST 2009
> D) If everything is a file, fine, that is a reasonable paradigm for
> addressing, CRUD, etc. So, what's in the file? And is reading and
> writing streams of bytes the right generalizing paradigm for pushing
> everything to? This is right back at the design problem of what
> comes after Unix pipes, for one thing. If we arrive at a grand
> unified typed semantic (GUTS) but simple lightweight graph (GUTS
> Graph) interchange, then fine, maybe.
Think UNIX device drivers; or better, Plan 9 device drivers and file
servers. Though at some level you are still "reading and writing
streams of bytes" those bytes in many cases have structure, and
(particularly in Plan 9) even multiple structures / formats are
acceptable. There's a strong congruence to POST here.
> E) Is everything-a-file a reasonable paradigm-for-everything? Or,
> after totally solving that problem, do I then have to solve a
> parallel but similar problem of protocols for pub/sub, message
> queues, database, streaming, services, etc. Can't we solve this once
> and layer the semantics for each view style on top? Filesystem,
> database (SQL, SPARQL, NOSQL, value store (key is Merkle hash),
> objects with swizzling), Imap, web, pub/sub/messages (Buddylist/IM/
> Twitter/RSS/Skype), etc.
and similarly, Sean Conner says:
> The web is a filesystem? News to me (and here I was taught that
> filesytems were a type of database with only one indexed column).
Everybody gets hung up on files, because we think of files as a static
bag-o-bytes and directories as single-indexed static entities.
Instead think "everything is a resource" and think of filesystems as
resource namespaces with some namespace composition (e.g. mount,
stacking where that's allowed, etc.) thrown of top. (This also
addresses Mr. Conner's concerns as well. The more-robust notion of
namespaces and resources within them evidenced in Plan 9 leads to
great user flexibility and simultaneously great parsimony in
implementation. It should be more extensively studied. If you think
you know what a filesystem is but haven't actually attempted to live
in Plan 9 for a while, you're missing a lot IMHO...)
Dr. Ernie asks:
> BEEP doesn't seem to have taken off?
Too markup-centric? Too heavy? Unnecessary given layering on HTTP?
Too much firewall friction for new protocols? HTTP as highlander-
protocol? ("Port 80. There can be only one.") Just a few thoughts.
Ivy seems interesting, too, but not much uptake there either.
Re: everything-a-file, Beberg opines...
> No, it's one of the fundamental misunderstandings of way back then,
> reasonable for almost nothing.
> Everything is a message.
Reasonable for almost nothing... except that the bulk of our
planetary infrastructure runs on systems that make that assumption (or
equivalent ones) to a greater or lesser degree. (And to the extent
that it's "to a lesser degree" --- well, that's where we get impedance
mismatch and abstraction-leak. You can thank Bill Joy and a host of
other stoned grad students sitting in a hot tub in Tahoe during a
"study junket" around ~1980 for creating the first cracks in the Grand
Unified Theory of UNIX.
But Beberg's is actually a reasonable point-of-view. It's also
manifest in Erlang (well, everything in Erlang is a process *or* a
message, and they are different; files also break that in Erlang but
Joe has already stated that he now things files should be modeled as
processes) and even moreso in the higher-order mobile pi-calculi
(where everything is a process, including messages). For the most
part I think there's a large equivalence between most of these points
of view; basically, you win when you get to a point where "everything
is a... x" (or rather, you minimize the number of kinds of things that
things can be) and they all support a rather generic interface,
putting a large part of the semantics in the composition /
coordination / communications and in the values of the communications
The filesystem / resource space view of the world is interesting as it
unifies the naming and interaction aspects of things. "Everything is
a message" doesn't necessarily address dynamics, which resources in
web-space and devices in filesystem-space do; in "everything is a
message" you end up with two distinct classes of things, messages and
things that can be messaged. (If you say the latter are also
messages, then I'd say that's interesting but I'm not sure how to
think about that. ;-)
Nonetheless, there's a very important and interesting point of view
lurking in Beberg's utterance. If you think of "files" (in the usual,
static, bag-of-bytes or even structured sense) as named messages from
the past to the future, from some producer to some arbitrary number of
consumers, you get some interesting mileage. Even moreso if you
separate the notion of the persistently-identified / named objects and
their state vector (or rather, graph) of individually immutable
versions (think implicit versioning in the filesystem; cf. Amoeba
It's worth pointing out that in most of these things except for the
pure higher-order mobile pi-calculi, you do in fact end up with at
least two classes of things: the communications between first-class
entities (which may be first-class in themselves) and those entities
(which generally capture both or either of any "static" named content
and any named services.)
Random thought re: actual filesystem implementation. Assume immutable
file objects, persistent identity across versions, and so on ala
Amoeba. Amoeba separates directory services from its "bullet" or
chunk store, as is the normal pattern these days. However: if you
have effectively separated the notion of persistent IDs and version
graphs and have immutable storage of chunks in a flat / hashed
namespace, could you not then implement e.g. directories as simple,
versioned files on top of that? Can you not model directories as
files, too, in that kind of a system? Dispense with the notions of
inodes, dirents, and all the rest --- replacing them with simple name
and namespace-composition mechanics and particularly-formated
versioned files? (And: where do you put the metadata? Also: logs,
read-write shared files / objects, etc. become difficult. I have an
idea for that, too, that basically couples OT (operational transform)
theory / patch theory (conjecture: patch theory is a subset of OT
under certain constraining assumptions) with the way Amoeba treated
"uncommitted" file objects.)
Just more musing,
More information about the FoRK