Date: Tue, 04 Sep 2001 11:00:37 -0400 From: Michael Sinz <msinz@wgate.com> To: Charlie Root <root@twwells.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Should URL's be pervasive. Message-ID: <00000925020cf507d1@[192.168.1.4]> References: <000003ff0207cf07d1@[192.168.1.4]> <000006fd020acd07d1@[192.168.1.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
Charlie Root wrote: > > > What I was trying to say is that there is no reason that I should care > > if the file is local or not. > > You do need to know if the file is local or not. You need to know > for security. You need to know because files behave differently on > different machines. You need to know because file structures don't > map from one machine to another. You need to know because > differing protocols allow you do to very different things to > files. You need to know because performance varies dramatically > depending on where the file is located. Ok - so my server here has files that various platforms access via NFS. The fact that everything accesses the files via NFS does not reduce or change the fact that the endian nature of the platform or the word size of the platform need to be either understood or that the file format be strictly structured so as to no matter. And if you think that each application needs to know about the different semantics of the file storage system, why is NFS just like FFS just like UFS just like FAT16 just like... Each has different limits and behaviors. NFS is very stateless. Local file systems are much more stateful. FAT has file name restrictions (pre-VFAT it was 8.3 with upper case only, for example) ISO9660 has depth limits and version numbers, VMS has version numbers and different character exclusions, etc. Some of these limits are annoying and, in some cases, incompatible with the work you may wish to do. However, most of these are limits that are also limits on other file systems (albeit different - 32 character names or 255 character names, for example, but still a name length limit) Performance differences are vast, even with local files. Have you written to a floppy lately. Almost all my network connected disks are *much* faster. How about that slow MO drive? Or that ultra-fast SCSI RAID pack? At some point the performance issues are just "if you use X it will not perform like Y" and not a "this program can't use X because we feel it does not perform well enough and thus we did not code for it." (cp, mv, etc, all work with floppy disks and other slow media...) > > Just as the OS support having multiple storage devices and media and the > > software does not need to know if the file is on a SCSI or IDE disk or if > > it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if > > it is local or on the machine beside it or on the machine on the other side > > of the world? > > The OS support of multiple device types exists because it is > possible and reasonable to abstract each of those device types > into a single "virtual" type. When this isn't possible or > reasonable, it's not only difficult but *wrong* to abstract. There > are way too many things you can do with a local file that you > can't do with a remote file to allow this abstraction. I never said this was trivial. We (which includes me) tried to start such a project at Amiga (Commodore) - It was well before HTTP was so popular. The goal was to hide the specifics and provide a single operation. FTP support was via a local cache while the file was open and if you did a write, it would write back the file at close time. This is due to limits in the ftp protocol, but it did not change the behavior to the application. The fact that writes were not instant to the FTP server was just one of the differences between it and other file systems. NFS had other limits. Our own network filesystem had yet other design goals and thus different limits/behaviors. The hard part we faced was the fact that the computers were much less powerful than today (slower/less RAM/ etc) and that Amiga(Commodore) was not very focused on networking (or anything else other than loosing money :-) > > Anyway, the point is that a file that I can access should be a file I > > can access via VI or MORE or EMACS or GREP or any other tool without > > having those tools each having FTP and HTTP and SSH support built in to > > them. The OS should handle it. > > No it should not. It's not reasonable for the *operating system* > to know about every damned protocol that someone decides would be > a just peachy way to access a file. Hell, it's not even practical. Not every protocol - or maybe every protocol supported by people who make the protocol filters. This is where external (to the kernel) protocol filters fit in well. But lets not go there (now). All of this started with the quest for URIs being useable everywhere. That is a nice starting point for an idea. Now, if I gave you foobar://xx/yy you might not know what to do with the foobar protocol from the URI. That would be an error, much like but not exactly like, file not found. (It would be unknown protocol as a subset of file not found, much like when you use /var/lof/messages when you were going to use /var/log/messages) > The idea of universal abstraction just does not work. If you think > otherwise, I suggest you start coding and stop bothering the rest > of us until you've made it work. I was not asking for a magic bullet. (Well, not this time :-) I was asking that the OS support reading and/or writing of data (whatever that may be) to a file/filehandle that was created via a standard system call. The data itself will have to be correct. I don't want to make some magic XDR type of thing. That is what XDR and/or file format definitions are for. But why should VI or EMACS have to have special code in each editor just so you can load/edit a file from FTP rather than local? -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00000925020cf507d1>