From: Brent Callaghan (Brent.Callaghan@eng.sun.com)
Date: 05/28/98-03:16:20 PM Z
Date: Thu, 28 May 1998 12:16:20 -0800 (PDT) From: Brent Callaghan <Brent.Callaghan@eng.sun.com> Subject: Re: NLM issues Message-ID: <Roam.1.1.896382980.9580.brent@jurassic> > Instead of contemplating one large > protocol which solves all of the problems that may be chosen to be > solved, why not use multiple smaller protocols which can each be > focused on a subset of the problem space? That way, each subset can be > focused upon by those with particular interest and expertise in the > area without having to be burdened by the rest of the problem space. > Each portion could be revised independently and at its own rate, > without perturbing the rest of the support being designed and/or > implemented. I'd hate to see NFSv4 become "fat" with features, though I'm not averse to some incremental weight gain if the protocol can be enhanced over time with minor revs. I do like the idea of "protocol layering" that allows the NFS protocol to be used as a "pick 'n mix" with other protocols, but I think it would be a mistake to go too far in that direction. For instance: - It's awfully convenient if the a client can get a reasonable level of file access via a single TCP connection to a well-known port. Requiring a client to make multiple connections to multiple services is not appealing. - Allowing clients to combine operations to tailor their requests serves heterogeneity and addresses Internet latency, e.g. lock a file and read some data - followed by write/unlock. This would be impossible if locking is carried out in a separate protocol. I think it's reasonable that locking be included in the "core" NFS protocol. But we should be very averse to throwing anything else in there that could live successfully as a separate protocol - there I agree with you. Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:46 AM Z CST