On 11/26/20 7:12 AM, Roman Danyliw wrote:
Perhaps I have imperfectly separated out all of the points. Remote file system access is useful for many reasons. Being able to treat remote documents very similarly to local files, without each application needing specific support for that access, is useful, and one of those benefits (among many others) is that the same application can seamlessly access documents from different locations at the same time. The editor with windows was just one example from my own experience, citing something that I do fairly regularly.- 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.Multi-editor windows doesn't seem tied to mounting a remote filesystem via FTP at all. Likewise, I'm not sure why a web-browser needs to be used at all. A remote filesystems seems to be about the convenience of accessing the files.
Up front -- there is no way to currently mount a remote filesystem from IETF services with anytime but FTP.Ah, the rsync argument again. Yes, you can do the same with rsync IF you have the storage to spare (my phone does not, many laptops with SSDs do not), IF you know about rsync and IETF's rsync service, IF you want to take the time to set it up, IF you have the bandwidth to spare to sync things. In short, you can do this IF you make lots of prior arrangements and maybe IF you don't pay for bandwidth.I will point out that the equivalent if this workflow (command line manipulation of directories of files) can be done by rsyncing the repo (whereby making an explicit cache) and all CLI sequences should work. Several GB of explicit storage will be required though (so perhaps this is a constraint). It also might be that case (all depends on the file driver's caching strategy) that if multiple commands which inspect a large number of drafts are used, it may be faster and use less bandwidth (e.g., grep multiple times across all I-Ds).
But rsync comes at a cost too. Every software package that runs on a computer is something else that has to be installed and configured, something that can break, something that may need to be updated (and which can break in the process), something that needs to be monitored if it's to be available when needed, etc. In other words there is overhead associated with every software package. For business and personal reasons, I run several different computers, and for each of them there is a list of things that "need" to be done - packages installed, updated, perhaps compiled, configured, tested, sometimes bugs fixed. So every one of those items has an uncertain amount of time burden associated with it, time that generally isn't billable to a client, time that gets in the way of paying work. Rsync is just another item on that list, another thing that takes an uncertain amount of time to get working, another thing that needs to be watched once in awhile so that the service it provides will actually be there when it's needed.
The same is true, I imagine, for IETF's running ftp - it's seen
as a nuisance, as overhead, something else that can fail,
something else that can be a security risk, maybe something else
that the CDN would bill for if it were outsourced, etc. But the
"you don't need FTP because you can use rsync" is an argument that
everyone who needs file-level access to RFCs and I-Ds should
have to separately incur the overhead of maintaining rsync
so that IETF staff doesn't have to maintain FTP. We don't know
for sure how many "everyone" is, but it appears to be at least
dozens of people, maybe more if you sample for more than 12
days. (I wouldn't expect everyone who uses FTP to use it once in
12 days, far from it.)
IMO the correct posture for IETF should be "how can we help
document authors, editors, reviewers work as effectively as
possible?" If there's any significant use of FTP - and dozens of
users in 12 days relative to ~1000 regular participants (if judged
by meeting attendance) is significant - continued support
for FTP should be seriously considered. Several dozen document
authors, editors, reviewers getting work done more easily should
be considered a boon more than a burden.
And sure, maybe WebDAV would be a better choice - maybe it would
facilitate ready access to RFCs and I-Ds for a larger number of
users if Windows has built-in support for it. So maybe a
transition would make sense. But if you're trying to help IETF
participants effectively participate maybe a well-managed
transition (perhaps even with overlap) would be the most helpful
way of doing that.
Plugins into favorite editors doesn't strike me as a unique feature. I'm not a user of GNU Emacs, but I suspect you could load arbitrary URLs into your buffer by: C-u C-M-! curl -s https://www.ietf.org/archive/id/draft-moore-exclusionary-language-00.txt'
Yes, but I'd have to remember and type that URL perfectly, which
makes it a lot less likely to be an effective way of getting that
document. (For better or worse, the naming scheme for I-Ds s not
optimized for memorability.)
I'm not so sure about FTP being unique here. My personal experience is that the mobile app and OS feature set is very robust. I have sent RFCs to print from my phone/tablet +and imported text into an email too without using FTP.
So everyone using FTP should have to change their toolset so that IETF can avoid supporting one server that helps at least several dozen participants?
Do you understand that that likely translates to a significant
fraction of those several dozen people deciding that it's just too
much trouble to work with IETF any more, because the organization
is now imposing more and more arbitrary constraints on how the
work gets done?
Keith
