Xref: utzoo comp.protocols.nfs:287 comp.sys.mac.programmer:7794 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!portia!Jessica!morgan From: morgan@Jessica.stanford.edu (RL "Bob" Morgan) Newsgroups: comp.protocols.nfs,comp.sys.mac.programmer Subject: Re: NFS and Mac IIs Message-ID: <3894@portia.Stanford.EDU> Date: 24 Jul 89 19:32:41 GMT References: <5458@b11.ingr.com> <2596@mit-caf.MIT.EDU> <1272@intercon.UUCP> <8058@hoptoad.uucp> <1289@intercon.UUCP> <8100@hoptoad.uucp> Sender: USENET News System Reply-To: morgan@Jessica.UUCP (RL "Bob" Morgan) Followup-To: comp.protocols.nfs Organization: Stanford University Lines: 26 Tim writes, re Macintosh NFS clients: > Another of the bad points, as I've noted, is that the extra work you > are proposing may not even be feasible under the protocol. State > caching in a stateless protocol is a pretty hard problem to solve, > and may be insoluble without protocol extensions. One form of statefulness in NFS has, of course, been accomplished not by extending the NFS protocol itself, but by adding a Lock Manager protocol, implemented on Unix servers as lockd (how do other systems, eg VMS, implement it, or do they?). Perhaps if MacOS/NFS really requires stateful file service to perform acceptably there could be a "macnfsd" that could handle whatever needs to be handled (ala pcnfsd, which of course is a different animal altogether). Is anyone prepared to be specific about what the problems are and what might be done about them? Macnfsd would of course have to be ported to each NFS server, and would have to trade off between functionality and portability. I can't imagine anyone really defining something like this other than Apple, or an Apple-supported contractor. - RL "Bob" Morgan Networking Systems Stanford