From: Peter Staubach (staubach@nyday.eng.sun.com)
Date: 05/28/98-01:59:41 PM Z
Date: Thu, 28 May 1998 11:59:41 -0700 From: staubach@nyday.eng.sun.com (Peter Staubach) Message-Id: <199805281859.LAA01072@nyday.eng.sun.com> Subject: Re: NLM issues > > > > The main problem with NLM was that it was a separate protocol > > > from NFS. > > > > I can see how making NLM separate would make it less likely for people > > to implement it. But I think the main technical problems with NLM > > have little to do with the fact that it's a separate protocol. > > Why is it even relevant whether making NLM a separate RPC program number from > NFS was a major contributor to it not being common among NFS implementations? > > The only thing I can think of is that if the separation wasn't a > contributor, then that is a justification for continuing to make locking > a separate RPC program #. > > If all we have to argue about is whether to make NLM a separate program #, > then congratulations folks, we've aparently solved the internet and intranet > locking and filing problems, and we can now petitition IESG to issue the RFC. > > Fix locking (or decide that locking isn't an issue). If after that, making > locking and filing separate program #s is really important to people, then my > attitude is: "fine, who cares, it isn't important, I won't let my notions of > aesthetics get in the may". > > Please, move on to the real problems. > Actually, Mike, you were the one who proposed that the problem with NLM was that it was a separate RPC program number which inhibited its success. The reason that topics such as this are interesting and relevant, is that they may concern the architecture of the final NFS Version 4 solution. I am hoping that NFS Version 4 will be a distributed file system solution, not just a file access protocol. This solution will need to consist of many pieces and will have many facets. The problem space is much larger than simple file access. It contains file access, but also replication, locking, etc. It is not clear that one large protocol is the way to go. Perhaps, several smaller, but related protocols, akin the NFS and NLM protocols, might be a better solution. If we are going to combine all of the problem solutions into one large protocol simply because we are afraid that implementors will only do parts or so that we can get through firewalls, then we are focusing on the wrong things. We can solve the other problems instead of just avoiding them. So, to turn the conversation back to being constructive, I will make a proposal for people to consider. 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. Thanx... ps
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:46 AM Z CST