An adaptor is a hardware or software device that adapts one format to another.
Often the formats are both standards of some sort.
Before generalities we describe some specific adaptors.
PDP-10 magnetic tape controller
The PDP-10 was a 36 bit machine built when IBM was building high quality tape drives devoted to a media format comprising 8 bit bytes.
Dec and others built special controllers to attach such tape drives to their 36 bit machines.
How to square 8 bit bytes with 36 bit words?
Their controllers supported three modes of I/O and the reasons for these three is very instructive:
- 32 bits of one word ↔ 4 bytes on tape
- This mode is suitable for PDP-10 programs that must read and write tapes whose format is dictated by the world of machines with 8 bit bytes.
No special programming on 8 bit byte machines is necessary.
- 36 bits of one word ↔ 5 bytes on tape including one 0 nibble
- This is good for storing arbitrary blocks of core on tape so as to be retrieved later bit for bit.
Special programming on the 8 bit byte machines is necessary to read or write such tape.
- 72 bits of two words ↔ 9 bytes on tape.
- This is most conservative of tape and core space.
Special formatting code is likely necessary for both sorts of machines.
The first mode adapts the world of native 8 bit tapes so as to accessible by PDP-10 programs.
The 2nd mode adapts blank media and IBM tape drives to to the task of storing PDP-10 core content.
The 3rd mode combines the space advantages of both at the expense of possible hair in programs for machines of either persuasion.
Capros web server
Just now the design question of a Capros httpd (web server) program has been raised.
Here are some possible goals of such a program:
- A means by which a browser user can manipulate an arbitrary Capros object.
This would mean causing arbitrary invocations of some key.
In order to be invoked via http a key would have to be held by a ‘http handle’ and that handle somehow be available to the browser user.
Two schemes come to mind for what it means for a handle to be ‘held’ by a browser user:
- The user knows a secret which is somehow conveyed via https to httpd.
Httpd has a flat non-listable map from such secrets to key handles.
- Httpd maintains an ssl session with a browser and for the duration of that session maintains a mutable map from ‘pet names’ to key handles.
such a map might persist outside sessions with some authentication protocol at the beginning of a session.
- Another server design would allow behavior of the server to be defined by a web savvy Capros object over some span of time.
Perhaps the span is just one http request but I think I don't like that idea.
Another possible span is an ssl session.
These different architectures can be interdefined and the real question is how to bottom-out.