Hacker News Reader

Comment by bawolff | Hacker News Reader

I cant help but think that this feels like webDav on steriods, and webdav never really caught on.

I kind of think sometimes it makes more sense to layer on top of http instead of extending.

It kind of is layered on top, no?

WebDAV didn't really catch on, but the general product space of remote drives did. The problem with WebDAV is that like most Web* tech (and maybe Braid) it's design by committee in the abstract. To make remote drives work well for the end user requires a fairly complicated protocol with tons of ugly edge cases. The interoperable standards from committees approach tends to fail in those situations, whereas hard driving startups that use proprietary protocols they can iterate quickly tend to win.

Iteration speed > openness, when there's nothing to copy from. Standardization tends to be about bigger companies trying to commodify their competitors.

many proprietary protocols iterate themself out of existence, just because some of them survive does not mean its the better model. Look at the video codec space, proprietary codes have long lost and have gone the way of Real Media, Windows Media Video and many others. While H.26X which is the result of design by committee are used everywhere.

It might be a different scenario with (modern) codecs where to get good use out of them it helps a lot to ship dedicated hardware. That's not true of file sync protocols.

> Standardization tends to be about bigger companies trying to commodify their competitors.

Didn't you mean to commodity their complements? Like when Microsoft (software company) commoditied the hardware on top of where their OS ran.

No, I meant commodify their competitors. Big company has moved up the value chain and doesn't want others following them, so they standardize the tech at the level below. Now competitors are all implementing the standard and thus can't get an edge over each other, so they end up driving margins to zero via price competition and have nothing left over for innovation, whilst simultaneously reducing the bigger firm's cost by turning the lower levels they still rely on into a commodity.

WebDAV was really complex, and required (ugh) locking for concurrent edits, which really sucks.

Let's compare WebDAV with Braid for something simple like looking up the current version of the resource.

In WebDAV, you have to:

- Send a PROPFIND request to the URL of the resource you want to check. In the request body, specify the DAV:version-controlled-binding property you want to retrieve, using a custom XML syntax. Here's an example:

    PROPFIND /path/to/resource HTTP/1.1
    Host: example.com
    Depth: 0
    Content-Type: application/xml
    
    <?xml version="1.0" encoding="utf-8"?>
    <propfind xmlns="DAV:">
      <prop>
        <version-controlled-binding />
      </prop>
    </propfind>

- The server responds with a 207 Multi-Status response, with XML to parse:

    HTTP/1.1 207 Multi-Status
    Content-Type: application/xml
    
    <?xml version="1.0" encoding="utf-8"?>
    <multistatus xmlns="DAV:">
      <response>
        <href>/path/to/resource</href>
        <propstat>
          <prop>
            <version-controlled-binding>
              <href>/path/to/version/history</href>
            </version-controlled-binding>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

This does not yet give you the version -- it tells you a separate URL that contains the version history. So now you have to query that for the version:

- Send a REPORT request to that url, and in the request body, specify the DAV:version-tree report you want to retrieve:

    REPORT /path/to/version/history HTTP/1.1
    Host: example.com
    Content-Type: application/xml
    
    <?xml version="1.0" encoding="utf-8"?>
    <version-tree xmlns="DAV:">
      <prop>
        <version-name />
        <creator-displayname />
        <creation-date />
        <comment />
      </prop>
    </version-tree>

- The server responds with a 207 Multi-Status, with more custom XML for you to parse:

    HTTP/1.1 207 Multi-Status
    Content-Type: application/xml
    
    <?xml version="1.0" encoding="utf-8"?>
    <multistatus xmlns="DAV:">
      <response>
        <href>/path/to/version/1</href>
        <propstat>
          <prop>
            <version-name>1.0</version-name>
            <creator-displayname>John Doe</creator-displayname>
            <creation-date>2023-05-26T10:00:00Z</creation-date>
            <comment>Initial version</comment>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/path/to/version/2</href>
        <propstat>
          <prop>
            <version-name>2.0</version-name>
            <creator-displayname>Jane Smith</creator-displayname>
            <creation-date>2023-05-27T14:30:00Z</creation-date>
            <comment>Updated version</comment>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

You can find the versions in there, and if you then parse and filter to the most recent version, you can see that the current version is 2.0.

That was a LOT of work!

Now let's see it in Braid.

To get the current version, just do a normal GET or a HEAD, and look at the Version: header in the response:

Request:

    GET /path/to/resource HTTP/1.1

Response:

    HTTP 200 Ok    
    Version: "2.0"

    <body of resource>

That's it! It's that simple!

Braid is this simple because it is baked into HTTP. It turns out that HTTP itself is already very close to a State Synchronization protocol -- it just needs a few headers, and the ability to stream updated responses when a resource changes. I encourage you to check out the spec, and see how easy it is to do things that were complicated or impossible in WebDAV:

https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...

Looks really stupid when transfer-encoding chunked already exists for exactly this use case.

Transfer-Encoding: chunked is for something completely different. It is for streaming a single body that you do not know the length of. It does not define a subscription format. It does not specify versioning. It does not define a patch format.

Some people have suggested using chunked boundaries as a way to encode multiple responses to a subscription. Perhaps this is what you are thinking of. However, chunk boundaries cannot be relied upon to remain intact; they can be changed by intermediaries. The chunks are only an encoding of the transfer. They are not supposed to contain any semantic information.

Chunked transfer is also disallowed in http/2.

Reply on news.ycombinator.com