Revision ID?

[astronouth7303]

As part of the update process, can I suggest adding a Revision ID to updatable objects?

The Revision ID is an opaque identifier set by the server and used when a client wishes to update an object to make sure they're updating it based on the most recent version.

An update under versioning may be accepted or rejected (409 Conflict). If it is rejected, the client must request the current version from the server and attempt the update again.

I don't think the spec should specify anything about how the revision ID is generated or if or how the server tracks versions (or, if it does, make them optional).

[cwebber]

@astronouth7303 To be clear, would this be for the "partial updates" supported in the client->server "Update" portion only? (Are there other uses for pointing to a list of revisions you're thinking, or is this strictly for error prevention?)

[cwebber]

@astronouth7303 To be clear, would this be for the "partial updates" supported in the client->server "Update" portion only? (Are there other uses for pointing to a list of revisions you're thinking, or is this strictly for error prevention?)

[astronouth7303]

Applies to all kinds of updates. The server doesn't know what processes the client did to mutate the data, or what the user did to mutate the data. The primary purpose is to prevent parallel writes from overwriting (race conditions) or stale caches doing the same. Having a revision ID probably has uses in server-server protocols and cache busting in general (or use HTTP caching for that? Dunno, speculation.)

As for additional ideas of tracking history, I think that's a matter of discussion, and possibly should be left up to the implementer. One can debate if the server should give the full edit history or just the last edit timestamp. But my guess (as an outsider) is that you don't want full versioning for 1.0.

[astronouth7303]

Applies to all kinds of updates. The server doesn't know what processes the client did to mutate the data, or what the user did to mutate the data. The primary purpose is to prevent parallel writes from overwriting (race conditions) or stale caches doing the same. Having a revision ID probably has uses in server-server protocols and cache busting in general (or use HTTP caching for that? Dunno, speculation.)

As for additional ideas of tracking history, I think that's a matter of discussion, and possibly should be left up to the implementer. One can debate if the server should give the full edit history or just the last edit timestamp. But my guess (as an outsider) is that you don't want full versioning for 1.0.

[strugee]

This feels like it would be great as an extension. Especially since we're already in CR.

[strugee]

This feels like it would be great as an extension. Especially since we're already in CR.

[cwebber]

I think @strugee is probably right, it should probably be an extension, mainly because I think we've passed the point at which we could properly incubate this. But we should persue it as an extension and see where we can take it. (Note that there are a lot of questions to resolve; ActivityPub is "eventually consistent-ish" and definitely does not expect total ordering as it currently stands. Things seem to have mostly worked fine that way for social networking updates in Pump.IO and OStatus; that doesn't mean to say it's the best design tho? Can these changes be layered on?)

Update as a verb is an exception for allowing parital updates in the spec btw, and that's only over client to server. For server to server, Update replaces the object on the remote end entirely.

[cwebber]

I think @strugee is probably right, it should probably be an extension, mainly because I think we've passed the point at which we could properly incubate this. But we should persue it as an extension and see where we can take it. (Note that there are a lot of questions to resolve; ActivityPub is "eventually consistent-ish" and definitely does not expect total ordering as it currently stands. Things seem to have mostly worked fine that way for social networking updates in Pump.IO and OStatus; that doesn't mean to say it's the best design tho? Can these changes be layered on?)

Update as a verb is an exception for allowing parital updates in the spec btw, and that's only over client to server. For server to server, Update replaces the object on the remote end entirely.

[cwebber]

I'm labeling this "Postponed (revisit in future efforts)" which does really mean that we intend to revisit it in the CG; but I'm going to wait to close it until after our Tuesday meeting so that we can talk about it and I can give people a heads up.

(It's also somewhat related in some ways to this blogpost about "an even more distributed ActivityPub", which is something I believe we captured as wanting to explore in the CG?)

[cwebber]

I'm labeling this "Postponed (revisit in future efforts)" which does really mean that we intend to revisit it in the CG; but I'm going to wait to close it until after our Tuesday meeting so that we can talk about it and I can give people a heads up.

(It's also somewhat related in some ways to this blogpost about "an even more distributed ActivityPub", which is something I believe we captured as wanting to explore in the CG?)

[strugee]

I've added this to the wiki page documenting potential future extensions. https://www.w3.org/wiki/ActivityPub_extensions

[strugee]

I've added this to the wiki page documenting potential future extensions. https://www.w3.org/wiki/ActivityPub_extensions

[sandhawke]

@astronouth7303 Can we just use etags? I think they have the right semantics, and I think AP objects are web resources, but I haven't looked at this closely. Would that do what you want?

A separate question is whether to expose the etags within the data somehow.

[sandhawke]

@astronouth7303 Can we just use etags? I think they have the right semantics, and I think AP objects are web resources, but I haven't looked at this closely. Would that do what you want?

A separate question is whether to expose the etags within the data somehow.

[aaronpk]

would this be for the "partial updates" supported in the client->server "Update" portion only?

@cwebber it's actually more important for full updates, and less important for partial updates. With full updates, you run the risk of replacing the entire object with an older version. At least with partial updates you only risk replacing the specific properties with old versions.

[aaronpk]

would this be for the "partial updates" supported in the client->server "Update" portion only?

@cwebber it's actually more important for full updates, and less important for partial updates. With full updates, you run the risk of replacing the entire object with an older version. At least with partial updates you only risk replacing the specific properties with old versions.

[sandhawke]

Alas, I guess we're not using the HTTP verbs for this (PUT and PATCH) which already have all this logic in them. Maybe there's a way to say this is equivalent to that.

[sandhawke]

Alas, I guess we're not using the HTTP verbs for this (PUT and PATCH) which already have all this logic in them. Maybe there's a way to say this is equivalent to that.

[astronouth7303]

Yes, etags are conceptually very similar, and could be used if there was tighter integration with HTTP. So far the integration with HTTP has been very loose. (To the point that you could probably write a version for non-HTTP transports without much hassle.)

I'd have to read the specs if there's a standard logic for ETags with regards to PUT. The exact semantics I believe were left unspecified in HTTP/1.1 and it was left to WebDAV to actually define the logic.

[astronouth7303]

Yes, etags are conceptually very similar, and could be used if there was tighter integration with HTTP. So far the integration with HTTP has been very loose. (To the point that you could probably write a version for non-HTTP transports without much hassle.)

I'd have to read the specs if there's a standard logic for ETags with regards to PUT. The exact semantics I believe were left unspecified in HTTP/1.1 and it was left to WebDAV to actually define the logic.

[cwebber]

ActivityPub only supports GET/POST, which I think is what @sandhawke is saying... so if ETags match conceptually, the question is can they still be used with just GET/POST?

The decision to only support GET/POST dates back from long, long ago agreements (and resolved at length disputes) in the SocialWG.

[cwebber]

ActivityPub only supports GET/POST, which I think is what @sandhawke is saying... so if ETags match conceptually, the question is can they still be used with just GET/POST?

The decision to only support GET/POST dates back from long, long ago agreements (and resolved at length disputes) in the SocialWG.

[cwebber]

Also I wonder if @strugee or @evanp can give us more context as to how pump.io does things?

[cwebber]

Also I wonder if @strugee or @evanp can give us more context as to how pump.io does things?

[astronouth7303]

HTTP/1.1 will define nothing about how POST should interpret headers. Kind of the point of POST, it's a catch-all "I'm going to poke at this URL with this data".

[astronouth7303]

HTTP/1.1 will define nothing about how POST should interpret headers. Kind of the point of POST, it's a catch-all "I'm going to poke at this URL with this data".

[sandhawke]

Still, aligning with GET might be nice. And give guidance in case anyone wants to implement PUT, PATCH, and HEAD.

(All this is on LDP/solid, but we never got to the point of convergence.)

[sandhawke]

Still, aligning with GET might be nice. And give guidance in case anyone wants to implement PUT, PATCH, and HEAD.

(All this is on LDP/solid, but we never got to the point of convergence.)