TV News vs. Newspapers (i.e. Mailing
Lists vs. Bulletin Board Systems)
Until now ways of communication on the Internet have included mailing lists, BBS (bulletin board systems), and newsgroups. But which is the best? It is our belief that none and all of them are. What we mean is that there is no winner: each approach has its strengths and its weaknesses. And each user has his preferences.
Some people like to watch the news on TV; some use the radio for this purpose; some like newspapers and others use on-line services; in the same way some people subscribe to mailing lists, some to newsgroups and others frequently search BBS systems. But there is no absolute: if you are used to reading a newspaper every day this does not mean that you are never going to watch the news on TV. If you are in a hurry or you are doing something (like driving) you will probably use the radio; if you want a close look on a topic or you want to see something on a historical event you will read an article on the newspaper (if you still have it).
Up to now administrators
just decided which was the most appropriate for the expected needs
and end users did not have many choices. It is our belief that
the information should be available to you however you wish. Once
a discussion is started on the Internet, you must be able to retrieve
the contents and to add to them, no matter how you decide to browse
and add. If you want fresh information, let email reach you. If
you want to search in the line of a discussion, use a BBS that
holds all of the notes. If you like web browsers then use your
favorite one to reach a site with the messages posted.
With our prototype, we took a significant step in this direction. We decided to use Apple's Macintosh as server. For this purpose we used WebSTAR as web server, Apple Internet Mail Server (AIMS) for serving email and Macjordomo for the mailing lists. Actually, it is possible to use any other mail server on any machine as long as the accounts needed to run our system are created. It is also possible to use other mailing list servers. (For example, the email can be held by one or more UNIX servers running Majordomo, with an additional email account for our system). In addition, Eudora was used to let the system look for email from the mailing lists and send out the ones corresponding to messages posted on the BBS.
This group of servers was glued together using UserLand Frontier, a system level scripting language for the Mac. We used an existing web-based BBS from Dave Winer that runs thanks to Frontier's CGIs (Common Gateway Interfaces). The advantage of this type of BBS is in the fancy outline for the messages, the ability to use HTML (HyperText Markup Language) in the body of the notes; since all of this is on the web: this means a larger audience and, often, more friendly interfaces for the readers. An interesting feature of Frontier is its object database (OD) that is always resident in RAM when the Frontier's script is running; this can mean speed and, in many cases, it also means relatively small data bases.
The architecture of our system is as follows: directly on the network we have, on one side, WebSTAR, which serves WWW requests (HTTP), on the other AIMS which has the duty of moving email to the final receivers and sending outgoing ones.
WebSTAR is invoked when browsing the BBS; each page that it displays is obtained thanks to Frontiers' querying the internal message data base and preparing the HTML pages on the fly. In these pages there are also the forms to fill-in to add new elements to the discussions. Once the forms are submitted, Frontier processes them to update the OD data base. Concurrently with the update, an email is prepared with the same contents of the message posted and is queued (Eudora is launched, if not already active, for this purpose). The receiver of the message is set according to the value found in another small database in the OD. The database that is searched is kept with the correspondences between the discussions on the BBS and the existing mailing lists that serve corresponding topics.
On the other side we have the "email part" of the servers: AIMS deals at low level with the email; it is the post office of the system. Macjordomo uses it for reading incoming mail with new messages for the mailing lists. Each message that comes is then copied and sent to each recipient. One of the recipients must be the BBS itself, for which an account is created in AIMS. To check for mail addressed to "BBS", we have built a Frontier agent [Maes 1995] that invokes Eudora at regular intervals (posting messages on the BBS, creating new mailing lists and moving emails between mailboxes as needed).
We have tested the system
by letting it run for almost a week on three existing mailing
lists outside our domain and creating two BBS discussions and
corresponding mailing list on our server. The system behaved as
expected: no messages had any problem when retrieved from the
mail agent, no message was lost and all the necessary duplication
of information took place (BBS and email version of all messages).
Behind the Corner
This prototype was built for Apple's (Apple Computer, Inc.) internal use. In a company where there are an incredible amount of meetings, events and deadlines, it is likely that managers, researchers, developers or engineers will miss something; but the last thing that the management wants is that people are not productive as much as possible (meaning duplication of work, non-collaboration, non-use of resources due to a lack of knowledge, etc.); so if this happens through improper information circulation (this includes retrieval of obsolete messages or the inability to find old messages), then the problem needs to be solved and solved efficiently.
What we have tried to demonstrate is that there is no standard for communicating. Of course this is only a starting point and there is a lot of work to do in the direction of letting any information being retrievable in all the possible different ways and being sure that nothing is missed or lost.
A point we also wanted to stress is that a working prototype could be built in a relative small period of time thanks to the use of Apple technologies. Probably ours is not the most efficient and robust solution to the problem, but certainly it is one which was possible to implement very quickly and which could let us concentrate on our objective, exploring our views on new ways of dealing with the rich styles of communication available over the Internet.
What the authors dream of
is a perfect wired world in which, when you turn on your computer
in the morning, you can read exactly what you want to read and
what you were expected to. Not one single word more. Not one less.
[Hale, 1995] Hale, M. (1995). Scripting the Web with Frontier. MacTech Magazine, 11 (12), 57-64
[Maes 1995] Maes, P (1995).
Intelligent Software. Scientific American, 273 (3), 84-86
The research that lead to this paper was carried on while the first author was an intern at Apple Computer, Inc..
Apple, and in particular Jim Spohrer, are acknowledged for the opportunity.