Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing

It does [1][2][3]. It's not the most elegant, it's not without flaws, but it's there, and enough to build against. Proprietary services weren't bound by having to code against a standard, so they cranked out something quick (and mutually incompatible), skinned an attractive interface, offered it for free (!) and attracted lots of users, who in turn attracted more users with the network effect. This is why Facebook, Wikipedia, Google Docs, Github won, and protocols like WebDAV lost.

This future was crafted by the makers of web browsers themselves: first by shifting the focus onto rendering arbitrary mediatypes delivered by HTTP from focusing on the intrinsic builtins of HTTP as a protocol, and later by trying to "standardize" the rich interactivity offered by the likes of Shockwave, Flash, and Silverlight, creating more and more APIs inside the browser that allowed client-side Javascript to communicate with the underlying system. Web developers aren't blameless, but today's web is exactly how Google, Mozilla, and Microsoft, in reverse order, steered it since the late 1990s.

[1] https://tools.ietf.org/html/rfc4918 [2] https://tools.ietf.org/html/rfc3253 [3] https://www.iana.org/assignments/link-relations/link-relatio...



Saying that WebDAV lost to Facebook is a bit like saying HTTP POST and DELETE actions lost to Facebook.

I was thinking of publishing and versioning of a different kind. For example, right now the only way to see how some website looked 10 years ago is to go to webarchive.org. 5% of all links on the web get broken every year. Isn't that something worth solving more systematically? In this respect content-addressable Web is a very interesting idea.


It's interesting, but the average web publisher doesn't care, and might actually see being able to retrieve past versions of a page as a bug rather than a feature. So it's not clear why they would implement it, or store old versions of page data on their server, or make that data available to users even if it was stored.

The web exists because it's a bunch of 90% solutions glued together. It's New Jersey style. And that's what works and survives. And we should be incredibly suspicious of attempts to do ground-up rewrites, because such things almost never end well, and typically fail spectacularly.

There were lots of other proposed protocols besides HTTP that had more functionality and features, but were more complex to implement, such that they never caught on. E.g. all those OSI-stack protocols, the majority of which were basically DOA because they tried to do too much. (CMIS could in theory do some sort of versioned document storage and retrieval, although I'm sure OSI probably had its own protocol for that, which I've just never had to work with.)

WebDAV is the right approach, in that it builds on an established, working, well-tested and thoroughly implemented protocol and doesn't attempt some sort of crazy forklift upgrade. It's evolutionary, it's backwards-compatible, and it's probably extensible enough to do document versioning if someone really wanted that.

The problem is that there's a three-part chicken-and-egg-type problem between protocols and client software and content. The protocols need to exist before client software can implement them, client software has to implement them before content can be created that uses them, but client-software developers are often reluctant to implement protocols unless there's user demand, which only comes if there's content available. So we tend to only get protocol improvements when a whole bunch of people agree that "hey this would be really beneficial" and everyone leans in to get it done. AFAIK, there's not that consensus on something like versioned web to make it work yet.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: