[FoRK] HTTP 0.2, 9p, and op

Jeff Bone jbone at place.org
Fri Dec 25 08:18:21 PST 2009

Stephen opines:

> 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  
bullet, etc.)

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 mailing list