From: Gordon W Waidhofer (gww@traakan.com)
Date: 06/07/99-08:05:31 PM Z
Message-ID: <375C6C5B.9635013B@traakan.com> Date: Mon, 07 Jun 1999 18:05:31 -0700 From: Gordon W Waidhofer <gww@traakan.com> Subject: Re: Extended attributes Mike Eisler wrote: > > Mike Eisler wrote: > > > > > i consider sub-files to be one way to stored the extended attributes > > > described in the current protocol draft. > > > > > > i don't see a need for 2 kinds of opaque attributes, each of which are > > > identified by a string identifer. > The current protocol specification states that: > > "New mandatory or recommended attributes may be > added to the NFS protocol between revisions by publishing a > standards-track RFC which allocates a new attribute number value and > defines the encoding for the attribute." > > The above is a (imho, the best solution) solution to the problem you raise. > Uncontrolled textually named attributes that aren't opaque to NFS clients are > not good, IMHO. Controlled textually named attributes are no better than > Controlled numerically named attributes. And numerically named attributes are > better because they can be searched for faster than textual brethern. > > -mre I probably agree. I may be out in the weeds here. Not sure. Somebody along the way suggested that extended/named attributes be implemented as NTFS named streams. This is what motivated my original posting. Provided that named attributes are named by identifier number, and that this "BELOW" the API name space is distinct from the "ABOVE" the API name space, I probably agree with it. In your comments, you say you don't see a need for 2 kinds of opaque "attributes". The presupposes that attributes and subfiles are the same animal, and they are not. I'm suggesting that they are separate issues: sub-files, textually named above the client-side API (by the application), and named/extended attributes which are named (by standards track number sounds good to me) below the client-side API. So, returning to my original motiviation, as long as NTFS named streams, or any other subfile mechanism, is not misconstrued as an attribute, or vice-versa, OK by me.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:10 AM Z CST