Re: draft-toomim-httpbis-versions HTTP mapping (and WebDAV Versioning)

Thanks, Julian for your thorough feedback here! I appreciate your 
pushback where my understanding of WebDAV was overly-complex.

I believe you and I are now converging to the underlying semantic 
question of how *versions* and *resources* relate, that you identified 
in the other thread.

I'll follow up there, but ask a few clarifying questions here, to pluck 
some knowledge from your brain and close off any dangling threads:

On 10/30/24 3:20 AM, Julian Reschke wrote:
> Yes, WebDAV Version Control uses a centralized model. If you want a
> distributed system, it's not for you. Note that this is an issue WebDAV
> Versioning, not WebDAV in general.


Oh, the distinction that "WebDAV is not centralized, but WebDAV 
versioning *is* centralized" is new to me, and curious. Could you 
explain where you see this distinction?

It is true that the CHECKIN/CHECKOUT methods are specified in the 
Versioning doc, but the LOCK/UNLOCK methods are in the core WebDAV spec: 
http://www.webdav.org/specs/rfc4918.html#locking.

>> 2. WebDAV takes up URL space by requiring each version of a resource to
>> have a URL.
>
> I'd argue that this is a feature. If versions are different resources,
> they should have their own URIs. I don't think that content negotiation
> is the right approach; in particular as it does not work when different
> versions sit on different servers.


Just so I know I'm understanding you— when you say "content negotiation 
is [not] the right approach", am I correct in mentally expanding this to 
the sentence: "using content negotiation (specifying which version you 
want from a server using a Version: header) is not the right approach to 
requesting a specific version"?

If so, then I think I understand your concern, and will pick it up in 
the other thread.

>>     This was how we differentiate WebDAV in the spec:
>>
>>         1.1.3.  Versioning encoded within URLs
>>
>>             In practice, application programmers tend to encode versions
>>         within
>>             URLs:
>>
>>         https://unpkg.com/braid-text@0.0.18/index.js
>
> Why is that a problem? (and no, they don't have to)

It's not a problem in itself. I'm sorry that was confusing.

You've correctly identified a number of advantages to encoding versions 
in URIs. I accept these advantages, and create a lot of "Version URIs" 
myself!

My argument is to have a separation of concerns between "Versioned 
Resources" and "Resources for Versions of a Resource." I want a robust 
spec for how HTTP Resources are versioned that does not talk about 
creating new URIs. Then we specify how to map new URIs to those versions 
as a separate concern with a separate spec— reusing link relations and 
friends where we can.

And this segways to the Deep Question™ in the other thread!

Thank you!

Michael

Received on Friday, 1 November 2024 21:57:48 UTC