From: Srinivas Bharadwaj (sbharadw@concentric.net)
Date: 03/24/97-02:07:22 PM Z
Message-Id: <3.0.32.19970324120719.006895cc@smtp.concentric.net> Date: Mon, 24 Mar 1997 12:07:22 -0800 From: Srinivas Bharadwaj <sbharadw@concentric.net> Subject: Re: Structured Files At 01:34 PM 3/22/97 +0000, Carl Beame wrote: > >I think we are getting way ahead of ourselves with "Structured files", >"MIME types" and URLs. We need to discuss at an implementation level >what is the form and extent of extended attribute support. Is it feasible >to have an arbitrarily long storage area for extended attributes? Are >we talking about a separate file for each file on the system? What are >our constraints? Who do current operating systems implement this sort >of thing? (Mac OS, Solaris and ACLs, VMS and record structures and >ACLs ...) > >Does the server have to even recognize the attributes? If we simply >had a storage area for extended attributes all the suggestions on this >list so far could be satisfied. Here is a short list of *possible* >attributes: > >MIME-File-Type: >URL-For-Access: >Compression-Method: >Last-Backup-Date: >ACL: >Carls-Special-Flag: >Record-Length: >Character-Set: >Description: >Author: > >from this list all but ACL can be ignored by the server and just >interpreted by the client. > >What I am suggesting is that we move this discussion to the actual >guts of GETATTRIBUTES and once we have that part figured out. And if >we do decide to use an arbitrarily long repository for attributes we can >then come up with well-known attributes like the ones listed above. >Though if we can't support long attributes most of this discussion is >meaningless. > >Carl Beame > > I do agree that implementation ease or possibility is an important issue. I think that we must look at precedents to answer your question. Consider V2,; to implement V2 there was the need to go to vnodes, define a vnode layer on the Sun machines, etc. A bunch of Unix machines did vnodes too to implement NFS. The PC clients came along, and there was a whole lot more that had to be done, not to mention the games with the Int 21H redirectors, 8.3 etc. (this was no pushover in the old days) NFS V3 had Asynchronous Writes(ooh!!), Large Files, support for larger transfer sizes. Of these, support for Large Files was the only mandatory one(there too it was possible to not actually support Large Files, because it was on the wire). But doing Asychronous Writes turned out to be hard. It was important for client implementations that wanted to get rid of the sync. write bottleneck. But because it was optional it was ok. Can it be done on MVS easily was not asked then for the same reason. As for ACLs there was first CMW or ESV or whatever. Then there was a side band POSIX acl protocol, again we did not ask how it could be done under MS-DOS or MVS. Support for content info. and means of access, is analogous; an optional feature, and not affecting base V4, but full fledged and extremely powerful and useful to those who are willing to pay the price to take advantage of it. Every file in the file system also need not have this. In terms of implementation, it all depends, - one could put a cookie somewhere and make the first direct block hold the extended metadata(?!?) if the cookie is set, or in another file. (.filename.extended). It is ofcourse my hope that the implementations for this would be easily innovated for a variety of systems particularly Unix and NT. In terms of protocol, this is more than just the attributes of the file, it deals with the method of accessing the contents of the file.(and hence probably adding it to access). But this is not the major issue here. The major issue is that file browsers, web browsers and a wide variety of other applications have a generalized way of understanding how to access file content in the intranet, across the extranet and all over the internet. And if we take this on as a worthwhile requirement and are honest and true to it, the exact protocol that accomplishes this can be innovated by us. srini
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:39 AM Z CST