Re: [Tools-discuss] Rfcdiff v 0.12 feedback

[Jay Daley <[e-mail]>]

> On 2/06/2021, at 10:53 AM, Carsten Bormann <[e-mail]> wrote:
> 
> On 2. Jun 2021, at 00:34, Jay Daley <[e-mail] <mailto:[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…

Got it - thank you. So

1.  If this functionality was only for files accessible over the web then a GET could be used each time.

2.  If a local file needs to be uploaded then that has to use a POST to send it.  It could possibly redirect to a GET using a stored copy of the uploaded file to provide this functionality

3.  Any storing/caching of the output would probably complicate matters considerably as we then need to take into account versioning, change detection and so on.

Sound about right?

Jay
> 
> 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).

-- 
Jay Daley
IETF Executive Director
[e-mail]