Marshall Rose (firstname.lastname@example.org)
Sun, 21 Dec 86 10:01:45 -0800
Well let me try to answer that. I've only read the spec twice and
don't have it here in from of me but here goes...
FTAM is based on the notion of a "virtual filestore" (sound
familiar, huh?) The filestore consists of zero or more files, each
with an unambiguous name. Each file has a set of attributes (of
which filename is one) and some contents. The attributes have the
usual permission stuff along with a description of the kind of
information the file contains (e.g., iso646 ascii, octets, bits),
and a description of the access discipline (my term) for the file.
The contents is a binary tree. Each node in the tree contains
- node attributes:
length of arc back to parent
a flag saying whether data is attached to this node
- attached data (if any)
- a list of children
Now, there are a couple of ways that you can implement a UNIX-style
regular file. The simplest is to have just the root node with the
entire file contents as the attached data (as an octet string) and
no children. In this case, the access discipline is rather
inconsequential, since you can only get at one data element at a
time and there is only one to choose from.
Alternately, for a file like /etc/passwd, you might have a root node
with no data, and a child for each line in the file. The access
discipline would allow you to specify any child element you want
when you wanted to read or write.
There are in the spec, several document types and access disciplines
listed with pre-defined meanings. Others can be chosen via
"bi-lateral" agreement. In the NBS OSI Implementor's Workshop
Agreements, they have defined a new document type called "directory"
in which the nodes are, you guessed it, file names. Assuming you
had an FTAM server which supported that document type, an FTAM
client could do the DIR and NLST commands that we've all become so
So to answer your question: FTAM imposes on everyone the same
fairly general file model. Each FTAM server consists of a protocol
engine for FTAM and a localFS-virtualFS engine. For UNIX-like
systems, going between the two is rather restricted unless you want
to put a lot of smarts in your code (at which true UNIX-ites would
gasp, I'm sure people are reeling at my /etc/passwd example!). In
this case, the question of "is it ascii or is it octet-aligned or is
it bit-aligned" is something the localFS-virtualFS engine for UNIX
would have to answer. Now of course, if you had something like
DEC's RMS in your filesystem, FTAM makes more sense as there is a
closer match between the local and virtual filestores.
It is important in all of this however, to remember what OSI is: a
method for tying together dissimilar systems. This is done by
choosing a sufficiently general model which is (hopefully) a
superset of all existing systems, and then letting people code
local2virtual engines at the network boundary.
With respect to RPC, there are such notions in OSI. My favorite is
called ROS (Remote Operations Service) which is a fairly simple
invoke-result, invoke-error protocol with provisions to support
"once-only" execution of operations. FTAM is not meant as a
competitor to ROS (and quite frankly, had *I* designed FTAM, I would
have put FTAM on top of ROS), but is trying to solve a different
problem, which perhaps has overlap for certain applications.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:14 GMT