Related Info: Apple Event Mgr PPC ToolBox Event Manager Edition Manager

Apple's IAC in System 7

By Frank Alviani, Contributing Editor, Waukegan, IL

Inter-Application Communications - The Future is Rapidly Approaching

It was just one year ago that my first article on Inter-Application Communications was printed here in MacTutor. In it and the succeeding two articles Paul Snively and I described and implemented a facility for allowing programs to be written that could automatically communicate without bothering the user. Apple has “validated” that concept by making it a centerpiece of the upcoming System 7.0. This article will be a short look at the approach taken by Apple, and how it is going to change the face of the Macintosh forever. (If you work in Word 4.0 with Superpaint 1.1MS, the linked combination gives some hint of the feel of the linked-document future we are heading towards!) It is NOT an introduction to the actual programming interfaces.

In addition to the new world Apple is entering, DEC has an analogous concept called Compound Data Architecture (CDA). The similarities between a suite of IAC-linked documents on a Mac and a DEC compound document are enough to strongly suggest that once both are established in the marketplace, it will be reasonably straightforward to convert between the two systems. This is a non-trivial operational concern in mixed shops, and important from a marketing viewpoint. I would be mildly surprised if the two companies didn’t work together to ensure the interconvertability of their systems.

Apple has taken a layered approach to implementing their IAC facilities; this is consistent with the approach taken with the other toolboxes and a natural division based on the intended usage for each layer. The material that appeared here in MacTutor corresponds to the PPC-toolbox level in the Apple scheme.

Figure 1 shows the layering designed by Apple, intended to show how interfaces on one layer depend on the next layer down, and how the interfaces at the same level serve different aspects of a common requirement.

SuperPaint!Me:Write Ups:Apple-IAC Illustrations!Draw(107,129:203,179)

SuperPaint!Me:Write Ups:Apple-IAC Illustrations!Draw(103,56:350,178)

The PPC Toolbox

The lowest level provides the raw messaging tools: direct communication and “store and forward”. This level is not intended for user-interface usage. It corresponds most closely to the SAWS IAC system, although the details of the Apple implementation haven’t been spelled out enough to tell how similar the internals are (I suspect they are significantly different, since certain of our IAC facilities are placed in different layers in the Apple software).

This level services two classes of clients: the upper layer of the IAC system software, and non-event based “chunks o’ code” such as RDEVs, DAs, etc. In a sense, all code executing on a Macintosh will be on an equal footing, able to talk with any other code executing at the same time or in the future. It is very important to note that programs and processes do NOT have to be on the same machine to take advantage of the PPC facilities.

These tools open up various interesting possibilities:

• Programs would be able to preserve “state information” across sessions by using the store-and-forward facilities to send messages to their future incarnations.

• Cooperation between programs on networked machines - well beyond the capabilities of today’s programs such as Timbuktu - becomes practical. For example, an artist can be building an illustration for an article, on machine A, while the article is being written on machine B, and the illustration would be in place in the article even while being drawn. This could allow unprecedented cooperation.

• Control panel devices could be used to actually control executing programs, etc. For example, an intercom is one possible such device.

The “Higher Level Events”

For the programmer, there is a significant extension of the event manager: “higher level events”. This is intended mostly for “below the surface” program-to-program requests, many in the form of remote menu-command executions.

In order for higher level events to be extensible for the future, several fields in the existing message record have had additional usages layered on top of their existing definition (in much the same way that the Text Edit toolbox was extended).

As shown in Figure 2, the “message” and “where” fields are redefined when interpreting a higher level event. The “what2” field - message class - identifies the protocol that defines how the specific message in the “what3” field is to be interpreted. How are those message classes going to be assigned so there won’t be anarchy and inadvertent duplication?

Apple long ago put a workable system in place when it decided to use 4 character fields to identify resources, application signatures, etc., and that same system will be used here. Applications will use their signature (‘MACA’, etc.) as the message class they send; Apple is, as usual, reserving all-lower-case combinations for themselves. For each class of messages, there are 232 possible messages.

I expect that at first each publisher will independently define sets of messages that will allow his applications to cooperate. However, there was discussion at the developers’ conference of perhaps arranging a conference on AppleLink to support the growth of a set of industry standard, publisher-independent messages. This would be of enormous benefit to the user, since it would make the development of a universal scripting language (see the note about AppleScript later) much more likely.

Apple will define the message class roughly corresponding to the File and Edit menus (calling their protocol AppleEvents™ and using the signature ‘stdr’); the remaining classes are defined at the discretion of the developers.

The general method of using higher level events is the same that’s used for existing events - WaitNextEvent to accept events and PostEvent to send them. There are few options that don’t exist in System 6, but they don’t change current fundamental techniques.

Certain aspects of this API are still not completely worked out, and will require considerable care to do properly. For example, we now have the possibility of an entirely new class of VandalWare: programs maliciously misusing higher level events. Methods for assuring you are certain of who’s sending a message before you act upon it will be required.

The Publish-and-Subscribe Interface

The segment of most interest to the user is the “publish-and-subscribe” support intended to standardize the user-interface approach. This resembles the technique used in the SAWS IAC driver, and in fact some of the terminology is the same.

The phrase “publish-and-subscribe” was carefully chosen to suggest to users that there can be a slight delay between when data is published and when it is received; it also suggests that there can be geographic separation between the data source and destination.

Apple’s goals for the interface are as follows:

• It must be generalizable - usable for all applications

• It must be scalable - capable of dealing with large amounts of data (for database or multimedia work, for example)

• It must work cleanly with the existing Mac interface

• It must work over the network to support networked cooperative tasks.

Like the SAWS IAC suggested interface, the fundamental units that are linked are sections, not documents. A document can have any number of publishing sections and subscribing sections, and can in fact even subscribe to itself (a wonderful fractal demo took advantage of this fact!) The IAC toolbox called the Publication Manager includes support for resources that are required to track the status of these sections, thus simplifying the programming task. The sections drawn during the demos at the developers’ conference were all rectangular, but I don’t believe that is required (if it is it should be generalized).

Like the SAWS IAC driver, the Apple IAC support can be viewed as an extension of the scrap manager (which is in fact shown in Figure 2). This suggests that applications need the same types of facilities to support IAC - such as the ability to handle at least the standard data formats, such as PICT and TEXT. This minimal level of support alone can go a long way towards making sure that relatively arbitrary combinations of applications can be “integrated” smoothly; your application doesn’t need to know how to interpret every data format in the new universe to fit in.

Unlike the SAWS IAC driver, the published data is kept by Apple in external files. These “pub files” are standard, named files that have their own Finder icon. This approach provides considerably greater generality: by putting “pub files” on a file server such as AppleShare, any number of documents can subscribe to the same data. As with the SAWS IAC driver, the exchange of data from publisher to subscriber can be asynchronous. The System 7.0 enhancements to the file manager provide file-ID facilities that are location-independent, so that publication files can be moved around on a single volume without confusing the client (publisher and subscriber) applications.

Unlike the suggested user interface for the SAWS IAC driver, Apple’s interface explicitly requires intervention for data to be published; the suggested action is when the Save command is invoked. Subscribers in open documents are notified immediately; subscribers in closed documents are notified when that document is next opened. Explicit intervention was chosen to simplify the application’s programming model and to avoid problematic recursive situations. My experience in writing the original MacTutor sample program suggests that this is a good solution; deciding automatically when the fresh data is cooked enough to publish is trickier than it looks, and depends a good deal on the type of data being manipulated. My only suggested extension would be to also have an explicit “update publication” command as an alternative for programs where saving is a time-consuming operation, such as databases.

The subscriber, in the Apple model, is a somewhat passive participant; it normally will just display the data retrieved from the pub file. The user interface guidelines, however, do support the idea of adornment - style changes made to text, etc. by the subscribing application before displaying the new data. Scaling and clipping would be among the appropriate adornments to apply to graphic data.

A very useful facility available to a subscriber is “go to publisher”, possible because of the backlinks between files. Implemented according to the guidelines, this transfers control to the publishing application, after the document has been opened if necessary, and the section has been scrolled into view.

Establishing a linkage between two documents is straightforward:

• The user selects some data; the application calls the publication manager to create the section-tracking resource.

• The “publish” command is invoked. The application brings up a standard-file like dialog to name the “pub file”, and then creates it.

• The user goes to the destination document.

• A section is selected to be a subscriber; the application calls the publication manager to create the section-tracking resource.

• The “subscribe” command is invoked. The application brings up a standard-file like dialog to select the “pub file”, and then reads it.

• The link is established.

Again, the API is not finalized and there are rough edges that will need to be smoothed out before System 7.0 is unleashed on the world. For example, there is no record of the last time a pub file was used, so that there is no easy way to detect “stale” pub files. If you think junk files accumulate on your hard disk, with only you living there, think of what some poor AppleShare administrator is looking at...

Conclusions

The design of the IAC support in System 7.0 was very well done. It will be a reasonable task to incorporate IAC support into existing applications; interface decisions may be more work for some applications than the actual coding. The facilities possible are exciting even to jaded developers - the IAC session kept being interrupted by applause!

In the long run, for anything more complex than a letter to Aunt Sybil, suites of linked documents are going to become the norm due to the convenience of working with your personal favorites in each required specialty. This reduces somewhat the attraction of all-in-one programs such as Lotus’ Jazz and Microsoft Works, although it may prove that requiring no configuration at all is enough of a feature to support a worthwhile market.

Applescript is a nebulous future concept that kept surfacing during the developers’ conference without ever being clearly defined. It sounds like Apple’s syntactic Holy Grail - a single language syntax that is usable for MPW scripts, SADE scripts, and the user’s control of the machine as a whole. One planned feature appears to be that it will have facilities for users to send “higher level event” messages to programs. This would give them text-based application-independent macro capabilities, rather like Tempo.

As an example of what all of these facilities together promise, imagine you have investments in several high-tech stocks that tend to move wildly all over the chart. Keeping peace in the house requires that you prepare a chart every so often to prove that poverty isn’t just around the corner, and so you decide to automate the process to make it less of a nuisance. All it requires is a quick script that does the following:

• At midnight on the 1st of each month, launch your favorite telecomm program with a program to dial up your data service and download all the prices required.

• Launch your wordprocessor with the basic stock report ready to go, including the subscribers for the data values and chart of price gyrations.

• Launch your spreadsheet with a worksheet and macro that loads the new data and charts it. Both the data cells and the chart are publishers, so you save the worksheet and publish the selected data and chart.

• The stock report updated automatically, so just order it to be saved and printed.

• Close all the applications.

MacTutor programmers, of course, will almost instantly be creating scripts of far greater complexity, and there will no doubt be a column devoted to AppleScript programming, but this gives you some idea of the potential that will be available to us in the near future.

In a couple of years we will probably be working in an environment that has some characteristics of the traditional mini-computer: (1) Multiple “parallel” processes, with communications between them, and (2) At least 1 powerful scripting language that allows flexible automation of repetitive actions - but with the addition of almost universal data-interchange formats, a huge variety of off-the-shelf software, and a consistent user interface.

The change from single-program to multi-program workstyle is not going to be without experimental evolution unprecedented in computer history; we’ve never had enough power available on a widespread basis to make this new mode of working feasible. There will undoubtedly be several styles of integration at first, until the market determines which is most workable, for example. There may be conflicts for a while between message sets that make it a little rocky to integrate arbitrary combinations of applications. In spite of these caveats, I am looking forward eagerly to an IACed universe - and so should you.