RFC 195

Data Computers -- Data Descriptions and Access Language ✨

okay bestie, title block tea 🫖 this is RFC 195 from the Network Working Group 🦋. It's written by G. H. Mealy (HARV), filed as NIC 7140, dated 16 July, 1971, in categories D.4, D.7. The header doesn't list anything it obsoletes or updates, so no drama there 💅

According to the minutes of the NWG meeting in May (RFC 164), a unified approach to Network data management is being pitched to CCA 👀 This paper is about the problems that come with that and some possible ways to fix them 🔧 Parenthetically (yes, I'm being extra), I think a non-unified approach leads to even worse problems 🙈

My whole argument is built on some assumptions and what follows from them 🧠 Since some or all of them might be wrong, I'm stating them out loud. The steps from assumptions to consequences might look (and honestly might be) less than obvious, but they're all connected, and they all come back to one thing: we have to do business with a bunch of dissimilar HOST systems while making sure a user or user program doesn't need to know the details of how a file is organized or represented 💜 If that's the goal, the arguments are pretty direct ✨

Assumptions 💭

1. We face the usual set of naming, cataloging, protection, backup, etc. problems. (I only bring this up to dismiss it for everything that follows. In my estimation these problems and their feasible solutions are pretty well understood. Our real problem is reaching agreement on specifics while leaving enough ratholes for future expansion 🕳️)
2. Files stored will contain arbitrarily complex data objects. 🧩
3. The organization of any file (meaning how its structure gets mapped into physical storage by the data computer) will normally be unknown by the user. 🫣
4. Data items in files may be stored in arbitrary representations (e.g., those of the originating user's HOST rather than that of the data computer or some other "standard" representation). 🎲
5. Access to a file will normally be to some subset of it. (So the unit for transmission will usually be part of a file rather than the whole file, and access won't necessarily be sequential 🏃‍♀️)

Consequences 🌷

1. A method of data description significantly more powerful than what's commonly available now (like COBOL or PL/I) is required. The descriptions must be stored with the files. Data item representations and storage organizations must be describable. 📚
2. The data computer must offer a "data reconfiguration service", based on use of the data descriptions. 🛠️
3. A representation and organization-independent level of discourse must be made available for controlling access. 🎀

Data Description 🧁

Okay, plot twist: the descriptive facilities in ELl (References 1 and 2) are almost adequate as they stand 😭✨ ELl is an extensible language. Its compiler and interpreter are the principal components of a system implemented on the PDP-lO at Harvard. It lets you define arbitrary data structures out of a few primitive data types (BOOL, CHAR, INT, REAL, SYMBOL, MODE, FORM, and ROUTINE). These are the sort I called "generic" in Reference 3 🦋 For the EL1 implementation on the PDP-10, say, we'd have to add methods to describe a specific representation of INT, etc., plus primitive routines to convert between specific representations 🔧

In the ECL system (where EL1 is embedded), there is no rigid distinction between compile time and run time 🤯 If the arguments and free variables of a routine are evaluable at compile time, the routine gets evaluated and the value replaces the call. Even more, arbitrarily large amounts of a routine being compiled may collapse into values. For the data computer, this opens the door to tailor-made data reconfiguration programs that take maximum advantage of the data descriptions at compile time, instead of running in a strictly interpretative mode 🚀

Access Language 🗣️

Here I'm on less firm ground, ngl 🥺 Still, I think some of the ideas from Sattley, et al (Reference 4) deserve a look. Here's the quote:

"... Our proposal is a language for describing the transferable
features of files, in which conventional programming languages (e.g.,
FORTRAN, ALGOL, etc.,) can be embedded, and from which the
information necessary to optimize the use of secondary storage can be
easily abstracted.  This language defines our abstract model of
secondary storage in the same way that FORTRAN defined an abstract
machine.  This language should have (at least) the following
features:

  1. File declarations name the file and the elements in the file,
     and specify the range of forms that the elements can take.
     Each file has precisely one named element.  Each file includes
     the (maximum) size (in number of elements) of the file.

  2. Subsets of files can be created by means of grouping
     declarations.  Such subsets can be nested.

  3. Subsets of files can be named by means of naming declarations.
     Such declarations can also name individual elements of the
     file.  Some form of implicit naming, allowing language
     constructs such as GET ANOTHER TRIPLE, is included.

  4. Members of a set (i.e., elements in a subset or file, subsets
     in a containing subset or file) can be ordered by order
     declarations.  Some form of arbitrary but fixed ordering,
     allowing language constructs such as GET NEXT TRIPLE, is
     included.

  5. The portions of a file transacted with at a point of access is
     declared.  The size of this portion can be expressed in
     absolute or relative terms.

  6. At each point of access to secondary storage, an environment is
     described (or referenced) which contains those declarations of
     types (l)-(5) necessary to define the transaction with
     secondary.

A language with the above features makes no mention of hardware
devices, but it provides the programmer with the means of defining
the algorithm-dependent features of his files so that those files
might be transferred efficiently from machine to machine".

In the Sattley, et al study, the idea was that a compiler would take the source program and actually compile the hardware-dependent file accessing code. In our environment, we're dealing with control commands to the data computer (e.g., GET NEXT WALDO) and supplying the data computer with enough info to define a WALDO. The basic functions seem to be the same either way, just implemented pretty differently 💖

Quick aside: the original says "Movember 1970" in Reference 4. Yes, it's a typo, but citations are sacred, so I'm keeping it exactly as written 🙈

References 📖

1. Wegbreit, B. The Treatment of Data Types in EL1. Technical Report, Division of Engineering and Applied Physics, Harvard University, Cambridge, Massachusetts, May 1971.
2. Wegbreit, B. The ECL Programming System. Technical Report, Division of Engineering and Applied Physics, Harvard University, Cambridge, Massachusetts, April 1971.
3. Mealy, G. H. Another Look at Data. AFIPS Conference Proceedings, vol. 31, 1967 Fall Joint Computer Conference
4. Sattley, K., Millstein, R. and Warshall, S. On Program Transferability. Report CA-7011-2411, Massachusetts Computer Associates, Wakefield, Massachusetts, Movember 1970.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Larry Masinter 10/99 ] 🌈