From: Srinivas Bharadwaj (sbharadw@concentric.net)
Date: 03/20/97-02:35:15 PM Z
Message-Id: <3.0.32.19970320123513.006881e0@smtp.concentric.net>
Date: Thu, 20 Mar 1997 12:35:15 -0800
From: Srinivas Bharadwaj <sbharadw@concentric.net>
Subject: Re: Structured Files
>> >Sounds like a disaster to me. Now you need different methods to
>> >access the file depending on what you want to do with it (do you want
>> >to read records from the file? copy it? dump it? compress it?). This
>> >would not only be very system dependent (and thus has no business
>> >being in a standard), it would also break every application I use.
>>
>> Well, this happens on a daily basis on the Internet and it is not
>> yet a disaster.
>What happens on the Internet is mostly transparent open/close/read/write
>file access on byte streams, and I agree that it works pretty well.
>I don't want to mess it up by adding lots of new special-purpose
>functionality.
Here we part terms. The messy part of it starts if you have a HTML 1.x
browser and you access a HTML 2.0 or followon file(or internet object) and
the problem exists today. ("I have this .ps file or this .pdf file I can't
read" is already there). And the formats have multiplied exponentially. For
the Internet NFS V4 could thus become an alternative to ftp but I would
guess that it could be more than that.
What is more, most of what happens on the net is HTTP and you might have
heard of a protocol parameter called content-coding or a transfer-coding
in HTTP(gzip, compress etc. to
handle, yes to low-bandwidth), so I am not way off line. I
am talking about a very relevent issue on the internet.
>Sure, but trying to put application level functionality into a
>file access protocol is just plain wrong. Everything we've
>learned since the 1960s says that you want to move the complexity
>away from the common infrastructure (be it the operating system
>or the network) and toward the few applications that actually need
>it (and meanwhile, encourage them to get by with less). The core needs to
>be simple and flexible and not get in the way. A file access
>protocol is part of the core, something that gets used by lots
>of applications for various purposes. We don't want application-specific
>functionality in that core.
File System Protocols are in the application layer(of OSI).
There is nothing that says that they should do this or that.
I would like to remind you that there were no file access
protocols in the 60's or for that matter the Internet.
Simply put, "How is this file accessed?" is a question
that belongs in the file access protocol, not inside the files that you
access using the protocol, or through assumptions and conventions that are
created and continue to
be created on a daily basis or using hearsay.
As for using DCOM, the NFS V4 protocol should
tell you the following when you issue a generalized ACCESS
on the file - "to access this file, you need this client application(from
this place) which will talk DCOM to this server or broker". It should not
be necessary for me to
load the client application and then ask it to access the file(that is the
old paradigm from the 60's that we are walking
away from).
I am not asking that we do something impossible.
srini
srini
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:34 AM Z CST