Why it works the way it works
With the release of IC/VC (the iCalendar/vCard route layer), some explanation of the used mechanisms might be helpful. The button with the little envelope which you see in your Newton applications is actually a very powerful tool. It is a system wide context menu that allows to perform actions based on the type of data currently displayed. The actions are either application defined or available throughout the system. The latter ones are clearly more interesting.
Most Newton applications follow the same principle. They display a list of items which are stored in a soup and can be modified individually. Every item is contained in a frame and typed via the ‘class slot. The system wide actions are available based on this type. The most common use for these system wide actions is to send the current item via a transport to somewhere else. Other actions are possible as well (e.g. reading an item via MacInTalk), but they are also based on the item’s type.
I’ll cover the transport case here. A transport advertises which data types it can handle. The most common data types are ’text and ‘frame, but there can also be others. Indeed, if you look at the Names or Dates soup, you’ll notice that there are ‘person, ‘company and ‘meeting types. Does the transport have to know about all of these? Not at all. It would be quite difficult to implement for example an email transport that would have to translate every possible data type on the Newton into an email message.
Instead, route scripts are used. They provide the translation between the application specific data types and the more general “transportable” data types. IC/VC is an example of such a route script. It registers as a handler for the data types used by Names and Dates and provides them in a form Nitro can handle them. The OBEX part of Nitro declares that it will handle the ’text datatype, so that’s what IC/VC provides. With a little twist: types on the Newton can have subtypes, and IC/VC does not provide an object of the type ’text, but instead ’text/calendar or ’text/directory. The neat thing about that is that it is still text and can be send via any transport that handles text. Nitro takes the subtype into account and sets the appropriate OBEX headers according to that.
So what happens now when a user taps the action button? First, the system adds all the application defined actions to the popup menu. Then, it identifies the type of the current object (I’ll spare you the details what happens in an app’s overview). Based on that type, it constructs a list of route scripts that can handle the data type. The final step is to then determine which data type each route script will provide and compile a list of transports that will handle these data types. These transports will be added to the popup menu.
The double indirection of route scripts and transports is really well done and is one of the things that puts the Newton OS still so much ahead of the rest of the PDA world. And that five years after is discontinuation…