[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: representing file pathnames
Hi-
On Aug 9, 2012, at 7:22 PM, Howard Chu wrote:
> Michael Ströder wrote:
>> Chuck Lever wrote:
>>> On Aug 9, 2012, at 2:46 PM, Howard Chu wrote:
>>>> Michael Ströder wrote:
>>>>> Chuck Lever wrote:
>>>>>> We could also use an NFS URL, which would allow us to express the server
>>>>>> hostname, a port number, and the pathname in a single string. But both the
>>>>>> hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS URL
>>>>>> format employs a fixed pathname separator character.
>>>>>
>>>>> That's what I would prefer. Think of file browsers which can open the NFS
>>>>> mount point just by clicking on it. Same encoding steps as with file URLs.
>>>>
>>>> This seems the most obvious and natural solution (NFS URL). After all, you are
>>>> specifying an NFS resource...
>>>
>>> I've looked more closely at this idea. While it's got some surface appeal,
>>> NFS URLs (RFC 2224) don't specify a generic NFS resource. They specify a
>>> webDAV like resource that can be accessed with NFS, called WebNFS (RFC
>>> 2054, RFC 20550), which gives clients access via a so-called "public file
>>> handle," which is a degenerate NFS FH.
>>>
>>> WebNFS is defined only for legacy versions of NFS, not for NFSv4.
>>> Referrals are supported only in NFSv4. In fact, section 4 of RFC 2224
>>> specifies that clients try version 3 then version 2. NFS version 4 is not
>>> discussed.
>>>
>>> Thus, the form of an NFS URL might be rich enough, but the existing
>>> semantics are not equivalent.
>>
>> I see no reason why it should not be able to use NFS URLs and define the exact
>> usage of them for NFSv4. Maybe I'm overlooking something though.
>
> Agreed. AFAICS the semantics of the URL are for your actual application to
> define. We're not talking about URLs that are meant to be served up by an HTTP
> server.
>
> IMO RFC2224 is defective in that it specifies both the URL format and its
> associated access methods. URL formats are meant to be "Uniform" which should
> mean they are independent of their access methods.
In order to use the NFS URL format, I think we would be compelled to correct RFC 2224, probably by issuing an RFC that supersedes it. While certainly possible, I'm not sure the NFSv4 working group is prepared to hold up the NSDB draft for such an undertaking at this point. Naturally there may be simpler alternatives.
That said, I can present this design choice (the use of an NFS URL to represent an fs_locations entry in LDAP) to them for discussion.
Thanks for the excellent feedback.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com