[yajoe]

This isn't as serious of a proposal as some of the W3C documents on how XML and WS-* works with my name on it (among many, many other smarter people)... and I have a lot of sympathy for someone who had to deal with Win32 APIs (they are locally optimized but globally bad).

I have no love for XML, but the details tend to matter. And you are right that saying "use HTTP" is a bit hand-wavy. XML is great at serializing nouns when you want to enforce the schema of those nouns. It makes interop of nouns, verifying, quantifying, and some types of searches must faster and consistent. XML was a reaction to widespread RPC and endless bit-order compat that wasted so many lines of code. It comes from the same mindset as the people who made SQL -- "conforming to schemas is good and what most people want."

However, in the last 10 years we've seen that it isn't possible to conform to a single schema as requirements change, and that is why XML has generally lost favor to JSON. This is a similar reason why NoSQL wins in many cases over SQL.

HTTP, in contrast to XML, is a set of verbs (called methods) and identifiers (typically urls), which is similar to what a file system is. It leaves the nouns (the body in HTTP) to the application, but it does promote some properties (headers in HTTP) and have conventions for common properties (content-type). The big difference between HTTP and most file systems is that HTTP is stateless, whereas many file operations are stateful (get a handle to a stream, write to a stream, close the stream).

HTTP would work as the API for a file system because it provides pretty good addresses for both local and remote and relatively low-level operations.

HTTP also has the benefit of being widely adopted, even during the Cairo development, which would have solved the chicken-and-the-egg problem from the first essay.

Using HTTP as a file system has key drawbacks: Applications would have to be re-written to use both the new APIs and new mindset of possibly high-latency operations. You can't always assume that a particular endpoint will be available, unlike many assumptions about inodes.

So, do I think they should have done this? Maybe, there were a lot of variables at play. But, I don't think it is a crazy idea to use HTTP as the file system, and I predict we will see a popular -- nay, credible -- operating system use it within the next 5 years.

And I also think it's telling that even in the post-mortem hindsight, the author fails to see alternatives that were widely available in the industry because they weren't invented at Microsoft.

[MichaelGG]

I must be missing something. You could trivially wrap HTTP around NTFS files, and stick whatever header metadata in an alternative stream. I don't see how this solves anything at all about what Hal talks about regarding integrated storage. How does HTTP solve even the simplest of problems that the articles talked about? Such as a photo being in multiple collections?

As an aside: Your statement on XML versus JSON seems confused. XML and JSON don't require schemas. XML allows it, and JSON has multiple (IIRC) contenders to specify a schema. Because as it turns out, people dislike having to write boring boilerplate code by hand and would prefer a system to specify common things. (And eventually JSON'll come full circle with something similar to WSDL.) JSON's popularity is half JS, and half because XML foolishly requires the tag name in the closing tag, bloating the size, and half due to overly-complicated uses of XML, especially namespaces. Sane use of XML is identical to JSON, except requires more space.

[ams6110]

xml doesn't HAVE to have a schema. It just has to be well-formed. The main reason it lost favor to JSON is that the markup is so much heavier. Also too few people learned about the power of transforms with XSL, again this was somewhat painful to write because of the XML markup but it was a thing of beauty to use.