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:
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.
- 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.
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:
These different architectures can be interdefined and the real question is how to bottom-out.
- 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.