Re: Byte range PATCH

Julian Reschke wrote ---



 >
> Yes, there is at least one more (SEARCH).
 >



lol, you just made me scour the IANA registry trying to figure out what method you meant



>
 >>
>> not being in the core spec? Can we revisit that decision? Or if not, can 
 >>
>
> No.
 >



OK. If the solution to my PATCH issues is to define a new method POOCH, I just don't want to be told it isn't core, or have the rug pulled because we've decided standalone method definitions have to relate to something larger i.e. WebDAV or other historical usage.
 


>

>>
>> we revisit the definition of PATCH to decouple it from applying to a 
>> single target resource, to allow patch files to be first-class resources 
>> in their own right? 
 >>
>

> I don't understand what you're trying to say here. Maybe an example 
> would help.
 >



Googly-eyed Hitler cats:



[link] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0252.html



I built up to that by describing how RFC 5789 is diff/patch/filesystem-centric, and how I want it to be copacetic with DARCS patch theory. It's hard to revert a patch that only ephemerally existed as an HTTP request entity-body. The subtle difference is moving forward in time with a reverted representation, vs. rolling a resource back to a previous temporal state.



So DARCS considers patches to be first-order resources. In HTTP, this means we *ought* to be able to link to them in a PATCH request. A find/replace across a project, may be the same actual instructions applied to 1+n files. Or a stored procedure, i.e. apply googly-eye filter to a collection of 1+n Hitler kitties.

-Eric