[MichaelGG]

Can you explain a bit of how HTTP would actually help here? HTTP doesn't magically fix the issues of mixing content local and remote (latency, availability, etc.) This sounds like "throw more XML at it" except with HTTP instead.

[geocar]

No it doesn't. And those are important problems, but another very important problem that needs solving is getting everyone to put all of their content into WinFS and make all of their services available from WinFS. Using an existing system bypasses a huge part of that.

[dpark]

>Using an existing system bypasses a huge part of that.

Not really. I'm not sure it's any less work to move an entire app to use a new interface than to move to a new file store. Your mail app doesn't implement an HTTP interface that a unified search engine could consume.

[yajoe]

Really?

Exchange: http://msdn.microsoft.com/en-us/library/office/jj900500(v=ex...

Gmail: https://developers.google.com/gmail/gmail_inbox_feed (Search is only available publicly via SMTP and IMAP, which technically isn't HTTP, but the Gmail app is clearly using HTTP XHRs)

[dpark]

Yes. Gmail and Exchange are not apps running on your system. It's fine to say that remote apps should interface over HTTP, but this doesn't address any local apps that currently use custom data stores, unless the answer is to move everything online, which is a much bigger undertaking than making everyone use a consistent data store.

The HTTP proposal also ignores all the data your apps already have locally. Outlook already has your mail. Why go to the server?

HTTP also doesn't magically make consistent free-form queries work. So again, I don't see how HTTP really accomplishes anything on its own with respect to the goals of WinFS.

[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.