[FoRK] HTTP 0.2, 9p, and op

Stephen Williams sdw at lig.net
Thu Dec 24 10:39:00 PST 2009

Jeff Bone wrote:
> Mappings between namespaces and protocols , generic interfaces for 
> things like HTTP, 9p, and similar resourceful and RESTful protocols 
> (op, a latency-insensitive, more RESTful and less chatty 9p 
> derivative) have been much on my mind lately.
> This has been around for some time, but I stumbled across it again 
> yesterday and found it both amusing and highly relevant:
>   "A sane web protocol is not an oxymoron."  cf.  
> http://http02.cat-v.org/
> While the name and some of the content is tongue-in-cheek, the points 
> made are quite valid.
> An appropriately-defined subset of HTTP plus a standard collection of 
> resources and conventions around them can (clearly) stand in for even 
> sophisticated "filesystem" implementations and concepts ala 9p.  And 
> the much or all of the statefulness of things like 9p (which makes 
> them somewhat less than RESTful) can easily be dispensed with --- 
> making web space and generic "filesystem" namespace much more 
> congruent.  Existence proof, cf. op

A) Cool.  I agree.

B) Anything that continues to remain client/server rather than at least 
having a p2p mode is broken.  Especially anything new.  UPnP works 
almost everywhere now, thanks to Xbox 360 et al, Rendezvous is easy.  
You can tunnel most things through an HTTPS connection (i.e. a TLS TCP 
connection with anything inside).  We do not need to only cling to 
HTTP.  The syntax and encoding is fine, the half-duplex synchronous 
nature is not.  Anything sane in a general sense must be async, 
pipelined, channelized lightweight message oriented with end to end flow 
control and adaptive rate handling.  HTTP-like messages over BEEP or 
AMQP would be fine.  And why does everyone think that always implies a 
big hairy message broker / router / ESB?  (RabbitMQ et al.)  For most 
processes, build in the smarts to the code running the connection...  
Message brokers should only be needed for fan-in/fan-out communications 
concentration, high security arbitration and logging, large-scale 
pub/sub repeating, and intermittently connected clients with stronger 
persistent needs.

C) Where is libOpenSkype???  Give me efficient secure bulk pipelined 
encrypted bandwidth between multiple endpoints using any method that is 
most appropriate.  Let me stream, let me scatter-gather, multi-party 
Merkle-hash bulk transfer, etc.  I need it now.  I need it later.  I 
have always needed it.

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.

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.
>     http://lsub.org/ls/export/op.pdf
>     http://doc.cat-v.org/plan_9/IWP9/2007/10.op.esoriano.pdf
> It should be fairly clear to anyone familiar with both HTTP and 9p 
> that a semantics-preserving mapping between them is possible given 
> certain assumptions and subsetting / constraints, and that's even 
> moreso true for e.g. op...
> This all leads me to recapitulate my longstanding but much-contested 
> points-of-view:  DAV is horrible and should be avoided at all costs, 
> and the Web is a filesystem. The sooner both the filesystem and Web 
> communities actually acknowledge those facts and start hashing out the 
> consequences productively rather than unnecessarily amplifying the 
> differences, the better.
> Just a little pot-stirring for the holidays, enjoy!

Mmm.  Mmm.  Good.

> ;-)
> jb

More information about the FoRK mailing list