Use ETag in all examples in range patch about braid-spec HOT 24 CLOSED

@brynbellomy Care to do this one as well?

from braid-spec.

Huh? Why are you using ETags? Why not use versions? Am I missing something?

from braid-spec.

See discussion in #51. So for range patching (which is a general concept) we should be using the standard ETags. In the HTTP braid spec I think we can use Version and Parents (but I would suggest we also standardize how ETags should be constructed given Version and Parents and populate it as well.

from braid-spec.

I just read #51 and I still don't see why you are talking about ETags. Care to give the reason?

We defined Versions to solve problems in ETags. The idea was to use Versions instead of ETags.
If there's a problem with Version, then let's talk about it and fix it. But putting ETags in here instead of Versions just makes it confusing to me.

from braid-spec.

I would suggest we also standardize how ETags should be constructed given Version and Parents and populate it as well.

I don't think ETags are constructed based on Version and Parents. ETags suck for what we want. Let's just use Version.

from braid-spec.

Mitar, what I think happened is that Bryn wrote section 6 in braid-http, unaware of how this is solved with Merge-Type+Version information, and wrote something using ETags. But this was a mistake. We don't want to use ETags. We have a solution using Merge-Type and Versions. So the solution is to remove the stuff about ETags, not add more stuff with ETags to the rest of the spec.

So I would close this issue.

from braid-spec.

Agree with @toomim on this one. I basically wanted to use ETag to hold the version, or something that mapped one-to-one with the version, but didn't realize that ETag will vary based on Content-Encoding. Let's stick with Version.

from braid-spec.

So we have two specs here. I am saying that in stand-alone range patch spec we are not solving race conditions and explaining that the problem is there and how to solve it is a useful thing to put there.

In http-braid spec we then say that you can use Version instead of ETag, and so http-braid spec also solves this problem, yea! So this is an extra reason why to use it, you do not have to worry about race conditions.

But in stand-alone case you do have to worry about that. So we should keep that section and probably improve all examples, no?

from braid-spec.

We don't want to use ETags.

In Braid no. But when range patch is used outside Braid, yes.

We have a solution using Merge-Type and Versions.

Yes, inside Braid. But not outside.

from braid-spec.

from braid-spec.

from braid-spec.

Then I vote to kill the "stand-alone" section.

What has this with the stand-alone section?

The purpose of range-patch spec is to define how to use Range header for non-GET requests. So we cannot have a cyclic dependency between range-patch spec and http-braid spec. Let's just define range-patch spec on its own, and then in http-braid spec explain that you use Version and extend If-Match to work on Version.

from braid-spec.

Mitar, ETags don't even work for Range Patch, because they don't give you a version in time. A resource can switch from ETag 0 to ETag 1, and then back to ETag 0 again if its contents went back to match what it was before. So if you're trying to use ETags for versioning, the result is ambiguous. You don't know if the ETag is actually referring to a version from way back in the past.

This means that you can't use an ETag to refer to a point in time, for instance when you are specifying the Parents of a patch. If I am looking at a patch that went from one ETag to another, I don't actually know which versions that goes between! Depending on the interpretation of those ETags, the patch could actually be many different things. This destroys immutability. And merge-consistency, because if two peers ask for the edits between version A and B, they might get different sets of patches, and then they'll merge them in different ways.

So as they stand, ETags just don't work, unless you want to put a bunch of work into adding more information to them to disambiguate them over time. In which case, you're going to have to name it something different so that it can be backwards-compatible, and then you've basically invented the Version again.

So stop it with the ETags. They suck. If you really want to make braid backwards-compatible with them, let's work on it after this paper deadline. There's no point in going down this rabbit hole right now. It makes the whole spec more complicated and harder to understand and introduces problems that we haven't solved.

from braid-spec.

What has this with the stand-alone section?

You just told me that we need ETags and the Race Conditions section only to handle stand-alone patches. So let's just remove stand-alone patches, and the ETags, and the Race Conditions. That simplifies the whole spec dramatically.

from braid-spec.

So we have two specs here.

Yes, you invented a second spec. I don't think anyone else wants it, though, and it sounds like it's not complete. Let's remove it.

from braid-spec.

You just told me that we need ETags and the Race Conditions section only to handle stand-alone patches.

Where have I told you that? You need ETags and the Race Conditions section to handle non-GET + Range requests when used outside of the Braid, but still on HTTP. This has nothing with the stand-alone patches. Not sure why are you repeating that?

So we generalized Range for non-GET requests and this works on its own as well. Not sure why that spec could not define it to work on its own.

Yes, you invented a second spec. I don't think anyone else wants it, though, and it sounds like it's not complete. Let's remove it.

What do you mean it is not complete? It is complete. It defines how one uses non-GET + Range requests.

from braid-spec.

Where have I told you that?

Scroll up, you said it here:

So we have two specs here. I am saying that in stand-alone range patch spec we are not solving race conditions and explaining that the problem is there and how to solve it is a useful thing to put there.

In http-braid spec we then say that you can use Version instead of ETag, and so http-braid spec also solves this problem, yea! So this is an extra reason why to use it, you do not have to worry about race conditions.

But in stand-alone case you do have to worry about that. So we should keep that section and probably improve all examples, no?

I don't know what you are arguing about right now. To use ETags? The point is that they don't work. And we don't have time now. We have to submit in 80 minutes.

from braid-spec.

A resource can switch from ETag 0 to ETag 1, and then back to ETag 0 again if its contents went back to match what it was before.

Doesn't matter. The patch will still apply. And this is the important aspect in that case.

But I agree, it is not perfect. Ergo, we can reference people to Braid HTTP spec. But you are not referencing the Braid HTTP spec. You just use Version headers without a reference.

from braid-spec.

Scroll up, you said it here:

Sorry, wrong terminology then. It means to use the spec as-is. Independently.

from braid-spec.

Let's discuss this at some other time. Don't worry about this now.

from braid-spec.

@mitar, I'm sorry for the tone I used in this thread.

Maybe we can resolve this now. Do you still want to specify ETags in the Range Patch spec?

from braid-spec.

I found a resolution here and wanted to make a PR, but got busy with one other project. I will try to find some time to get back to all these issues and stuff soon.

from braid-spec.

@mitar Do you have anything left to discuss in this issue? I apologize again for lacking patience in the old discussion here.

from braid-spec.

I think this is OK for now. Let's close this. (I also do not remember what was the PR I wanted to make about.)

from braid-spec.