[FoRK] HTTP 0.2, 9p, and op
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.
> 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
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
> 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.
More information about the FoRK