Open groupware: mail-enabled applications

RELease 1.0, Oct 17, 1989

OPEN GROUPWARE: MAIL-ENABLED APPLICATIONS Remote procedure calls, precisely because they are so low-level, don't make much difference to the applications users see. They are non-disruptive, helping developers distribute an application invisibly. More interesting is a whole new kind of application (which can be built on top of RPCs): cooperative applications. This approach lets uses work ad hoc with a group of independent applications, and lets te applications work with each other.

One handy communication mechanism for cooperative applications (as long as they don't need real-time communication) is E-mail. E-mail enhanced with uses programming tools and interfaces to common applications and information sources provides support for end-user development of groupware. (All this requires a very different kind of tool from an RPC compiler, something on the order of a spreadsheet as opposed to a financial planning language. Remote procedure calls may underlie a mail system, as financial language routines underlie spreadsheets, but they aren't visible to most users.)

E-mail does not provide the power and seamlessness of remote procedure calls, but it's more accessible and error-tolerant. There is less advance coordination required. Remote procedure calls are synchronous, like phone calls, whereas E-mail is patient and non-intrusive, and provides a store-and-forward facility which can hold messages until the recipient -- person or application -- is ready.

Mail models

There are two budding standards for large-scale E-mail: IBM's SNADS (for SNA Distribution Service, which is part of SAA), and the TCP/IP Simple Message Transfer Protocol, or SMTP, which is evolving toward the formal CCITT X.400 standard. They correspond almost perfectly to SAA and UNIX -- in proprietariness, culture and consistency of implementation. (DEC's VAXmail is also widely used, just like VAXes.)

At the other end of the spectrum is Action Technologies' Message Handling Service, an open standard (you can use the protocol without buying the tools, but your users will need an MHS server from Novell, Action or a licensee). It performs similar functions, but isn't directly comparable: Differences in scale translate into fundamentally different systems. MHS is local, and works over local-area networks and asynchronous auto-dial. X.400 is global, and manages more complex data translation and a worldwide range of addresses ... but it doesn't scale down well and it requires fairly sophisticated network underpinnings (an OSI protocol stack) to operate at all. "X.400 is to an army tank," says Soft Switch chairman Mike Zisman, "as MHS is to a Volkswagen. They're both useful, but for different tasks." (Presumably, then, SNADS is a private tank.) All this means good business for Zisman, whose company provides gateways among local-area networks, the various proprietary enterprise-wide systems such as VAXmail and IBM's PROFS, and the X.400 standard.

MHS has been around for a long time as part of Action Technologies' The Coordinator, and was built as a quick, tidy elegant way for The Coordinator to handle messages. Novell encouraged Action to generalize it, and now offers it (via a free coupon) as part of every NetWare system sold. You can also buy it directly from Action Technologies (see Release 1.0, 86-10, 89-6). Until this year it hasn't had much of a following, but 100 people turned out for the first-ever MHS developers' conference, including ComputerLand, which uses MHS to send messages between warehouses to manage inventories and other data. Like all these communication systems, MHS consists of protocols and a message-handling (server) component. The primary protocol is an 18-line ASCII file that contains parameters describing where the message should go, whether acknowledgement is required, etc. At either end, each MHS application needs to know how to implement "seal" and "unseal" routines, creating and interpreting the 18-line header.

Mail-enabled applications

These standards are a start. Now we need interfaces so that they can carry messages to and from applications, instead of just transmitting files and messages between people.

What would such an E-mail-based system look like? As it happens, it would look a lot like the MIT Information Lens and Object Lens systems, designed with grants from Xerox, Wang and DEC among others and running on Xerox D-machines with a UNIX revision underway (see Release 1.0, 86-10 and 88-9).

Two start-ups are working on just such a system, with object-oriented user tools, but using more widespread pc platforms. Both companies have worked with the MIT project leader, Professor Thomas Malone, and he is co-founder and director of, and consultant to, one of them, Agility Systems. Malone also runs MIT's new Center for Coordination Science.

Both these systems fill a gap that struck us hard at OOPSLA: Lots of object-oriented programmings tools help you design application user interfaces -- with windows, dialogue boxes, radio buttons, scroll bars -- but none of them seems to know much about performing tasks, such as composing and distributing a memo, handling a customer request for a special service or planning a boss's itinerary. Nor do they know about programming interfaces to existing applications -- so that you could, say, get data from Dow Jones or a 1-2-3 file through a nice, user-friendly form, or request an advance through a nasty, scary form that asks the name of your first-born.