Hi Keith,
here is my workflow:
1. I have an idea that may be worthwhile to share with the community. At this point in time I have read various other documents and RFCs already. The outline is either in my head or written on paper.
2. I write the draft in my favorite text editor. Currently, this is Notepad++. I change editors all the time and do not feel emotionally attached to any of them.
3. If I need to verify text from a referenced RFC/draft or want to cite a specific paragraph then I open the draft/RFC in my browser.
There is little difference between swapping between two programs vs. changing between two tabs in an editor. Notepad++ has a multi-tab concept and so I could open an RFC in one tab and then edit my draft in another tab. I don't do that because I got so used to the app swapping. Does it require FTP support to do that? No, it doesn't.
Screen space is an issue with implementation work. This is where multiple screens are super useful. For example, I often have a draft open on one screen and use the IDE (uVision 5, Visual Studio, etc.) on the other. Having three monitors would even be better because then you can run the test scripts on the third monitor.
I also print drafts for review. Does it matter how quickly the print-command is invoked or even how fast the documents are printed? No, it doesn't because the time needed for the review is the dominating factor here. It typically takes me many hours to review documents. (FWIW the task of reviewing is still very much underappreciated even though it is very time consuming.)
Your description below (and thanks for the details) shows one thing: everyone has come up with different ways of working. Everyone likes their style most. Nobody wants to see a change (which probably extends beyond draft editing).
Regarding change let me give you an example from another organization I am involved in. We wanted to change the document format of our specifications from Word to Markdown and faced huge resistance. For the test specification, we have actually to switched from Word to Markdown, then from Markdown to HTML (because the test specification uses lots of tables, which is a mess in Markdown), and then we switched back to Word. Some people in the group got so used to Word that the transition to another format made them very unhappy. (Funny detail on the side: those who resisted most didn't edit a lot of documents.)
I believe the real question is how do we manage change in this organization? In this specific case, how long are we going to support workflows of a smaller and smaller number of people? (I assume that your workstyle is less common than mine. Maybe a bold assumption.)
Something to think about is whether you are trying to optimize your workflow for something that, in practice, doesn't really matter much. Think about the 80-20 rule. I believe you will loose very little by switching from FTP to HTTP in terms of overall draft writing productivity.
Ciao
Hannes
-----Original Message-----
From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Keith Moore
Sent: Thursday, November 26, 2020 12:50 AM
To: ietf@xxxxxxxx
Subject: Re: Regarding "Call for Community Feedback: Retiring IETF FTP Service"
On 11/25/20 3:25 PM, Hannes Tschofenig wrote:
> I am curious why you need these features.
You mean, you really don't understand why these features are useful and can save significant time for many IETF participants?
- An ftp server can be treated as a remote file system by many platforms. That means, for example, if you're editing an I-D and you want to refer to some other document, you can open that document in your favorite text editor without the editor needing specific support for FTP. If your editor has windows (such editors have existed since at least the late 1970s), you can see the I-D you are editing and the document you're referring to side-by-side with no wasted screen space. This is a LOT more effective than trying to deal with your editor in one window and a web browser in another, partly because web browsers and web pages both tend to make very poor utilization of screen space, but also because multiple windows within your editor have the same UI, whereas the web browser and your editor probably have different UIs. The same feature makes it possible to _easily_ print some set of documents ("lpr draft-*workinggroupname*.pdf), or copy some set of documents, or search through ("grep") some set of documents ("which internet-draft contains the text...") or ("which internet-drafts reference RFCXXXX?")
[I personally find printing is the best way to review documents because then I can easily annotate them with ancient writing utensils, which is far better than trying to do so using any keyboard-based tool I've ever seen. And I refuse to feel bad about that :) ]
- Some FTP clients have filename completion. So if you're looking for a particular file, you don't have to search through all of the text on a web page. Sure the web browser has a Search feature, but it doesn't distinguish file names from other text, and there's no assurance that the files you're looking for are all grouped together. Filename completion can be implemented fairly efficiently in FTP, because if you type "a" the client can do "LIST a*", then when you type "b" after "a"
the client can do "LIST ab*", etc.
- Most FTP clients support multiple file transfer via wildcards (e.g.
draft-*-workinggroupname-*) . Many support an effective "batch"
transfer UI: Select the files you want and press "start" or some such, and all of the files you selected are quickly transferred for you. This has been an effective interface for file transfer ever since at least the Xerox Alto, and has been duplicated by many clients since then because it works well. Web browsers generally require you to start each transfer separately, maybe specify a destination for each separately, and often, to manage them separately (they may queue up multiple transfers or do multiple concurrent transfers but you still have to go back and check to see that they were successfully downloaded because failures are common for some reason. The browser is really optimized around letting you read things rather than letting you transfer files, especially multiple files, robustly.).
- Similarly, many editors have built-in or plug-in support for FTP. A lot of Windows users like Notepad++ which has a plugin for this. GNU Emacs for Unix/Linux has an "ftp" command (M-x ftp) that basically lets you talk to the local ftp client on your machine, but it also ships with "remote file" support so you can directly open (for example) /ftp:ftp@xxxxxxxxxxxx:ftp/internet-drafts/draft-moore-exclusionary-language-00.txt
. Filename completion is supported here so at any point you can type ? to list potential completions or TAB to complete the filename as far as it can be given the alternatives available. MUCH faster than searching in a web browser.
- Using FTP, I can search for an internet-draft or RFC from my phone; I can browse the documents by name or date order or size; I can edit the document on my phone or import text into notes or email; I can send the document to a printer from my phone. Yes, the phone has a built-in web browser but many web sites are far from ideal for a handheld device. By contrast the FTP client is written specifically to be used on such a device, so it doesn't waste screen space AND it's more functional for some purposes than the web browser.
- And there's a lot of value in NOT expecting participants to learn a new interface when an old one works well. "The Web" is not better than FTP for all purposes; it's a different tool with different strengths and limitations. Expecting people to use new, crippled interfaces is not only a kind of age discrimination, it also deprives newer people of the ability to use those interfaces which could improve their productivity also.
A huge benefit of FTP is that the client can be small and relatively simple. That makes it feasible to embed FTP clients in very many applications, which provide improved user interfaces as compared to having to use a separate client to do file access than the one used to manipulate the files. That's not to say that you can't embed a web browser in an application - often you can - but then you don't easily get the benefit of an application that's well-tailored for your particular purpose and you also get a lot of baggage that you might rather do without.
Keith
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
