Re: [Tools-discuss] Rfcdiff v 0.12 feedback

[Carsten Bormann <[e-mail]>]

On 2. Jun 2021, at 00:34, Jay Daley <[e-mail]> wrote:
> 
> 
> 
>> On 2/06/2021, at 9:59 AM, Carsten Bormann <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> On 2021-06-01, at 21:26, Jay Daley <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> So that I’m clear - do you want to bookmark the GET in order to repeat the same diff?  In other words, if the result was stored indefinitely and a bookmarkable URL returned then would that be sufficient for you?  (not designing things here, just trying to understand the use case).
>> 
>> Not quite, because the file at one of the URLs might change.
> 
> I see.  Some more questions:
> 
> - I’m guessing, though I don’t know, that the reason for a POST is so that a local file can be provided in the form body, which a GET cannot do.  Is that a use case you use?

I don’t (I have local copies of all IETF documents + a local installation of rfcdiff).

I use the web page:

— when I get a new draft mail — there is a convenient diff link in there, and I’d need to rsync first otherwise (*).
— to send the URL to other people (via mail, via GitHub README.md, telegram, …).

> Of course it could switch from a GET to a POST in that situation but I don’t know what the impact of that is.
> 
> - Would a bookmarkable stored result with a 'refresh' button do the same thing?

I’d need these other people to press the refresh button.

> - Is this just a time saver or is there another reason not to use the web form each time?  

See above.

> I ask because there are time saving techniques that can be adopted on web forms - 'recent diffs', 'favourites' etc.

I have no control over other people’s favorites…

Grüße, Carsten

(*) which can be slow, because the RFC editor tends to update files that didn’t change, so rsync needs to check all these files each time.
I don’t know who I need to talk to about how to update a file offered for rsync (i.e., don’t, unless it changed).