XNSRemoteFileDoc.tioga
Copyright Ó 1990 by Xerox Corporation. All rights reserved.
Bill Jackson (bj), May 30, 1990 2:32 pm PDT
XNSRemoteFile
PCEDAR 2.0 % FOR INTERNAL XEROX USE ONLY
XNSRemoteFile
PFS Access to XNS Filing Services
Bill Jackson
Ó Copyright 1990 Xerox Corporation. All rights reserved.
Abstract: XNSRemoteFile is an implementation of routines for use by PFS in order to gain access XNS filing services. In general, users will not find anything interesting in here, please refer to the PFS docmentation.
Created by: Bill Jackson (exploiting Cedar7.0's previous FS implementation)
Maintained by: Bill Jackson <BJackson:PARC>
Keywords: XNS Filing, Courier RPC, PFS, ...
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
News
May 27, 1990 6:55:35 pm PDT - created this document
My goal is to get this code working, and to explain in this document the internal architecture so that maintainers will have a leg up when trying to sort out the implementation.
1. Internal Architecture
Interfaces <XNSFiling*.mesa>
Attributes - translation between Cedar types and Filing's AttributeValue(s).
FileMgr - isolation of (open) file operations - ??caching??
Names - translation between PFSNames.PATH's and Filing's pathname encoding.
Ops - RPC operations within the context of Session(s).
Private - stuff that isn't big enough to live on its own.
Session - connection management.
Implementations <XNSFiling*Impl.mesa>
Attribute - implements Attributes interface; it's primary function is to translate between native Cedar Language types and Filing's AttributeValue(s).
BDT - implements Private interface; it's primary function is to translate between native Cedar Language types and Filing's BulkData STREAM OF Attribute.
Error - implements Ops interface; it's primary function is to isolate RPC-based errors and to translate both them and Filing's errors into PFS.Error.
Ops - implements FileMgr & Ops interfaces; it's primary function is to encapsulate RPC operations for use with Files, Sessions & View.
Path - implements Names interface; it's primary function is to translate between PFSNames.PATH's and Filing's pathname encoding.
Session - implements Session interface; it's primary function is to isolate connection management.
View - implements a PFS View; it's primary function is to provide access routines to PFS. A big goal is to not have much code in this module.
Other Modules
XNSFilingTestImpl - a place put some handy test code while developing
XNSViewSnaphot - a copy of the PFS Template routines before implementing XNS Semantic operations. This should be helpful for others who want to implement a PFS view.
2. Issues
Monitor Locking
I've tried to keep locking to an absolute minimum. One reason why there are so many files and why the abtractions are broken up the way they are is to identify the race conditions and to help find the binding between layers, especially the contention or races.
XNS Sessions
I've tried to keep CrRPC, Authenication and Operations logically independent. This should allow for transport caching, multiple identities and simpler Filing operation code at the cost of having to wrap your head around a bigger intellectual system.
Open Files
It is interesting to note how PFS manages files. There is no retained relationship between (open) files and the server used to open/operate-on the file. This means that you either have to keep the server state alive artificially, or you have to be prepared to reopen your service connection in order to perform an operation (e.g. read/write). I'm still trying to allow both modes.