At present, in addition to their functions as individual conceptualization aids and stationery, personal computers are drawing attention for their function as so-called "communication machines." Users are making great use of data search/reading utilizing the World Wide Web (WWW) and personal intercommunication using electronic mail.
Accordingly, in the Sakamura Laboratory we are currently constructing a software environment that can handle the WWW and electronic mail on top of BTRON. In this paper, I would like to explain one of the two: the software environment for handling electronic mail.
In designing an electronic mail environment on BTRON on this occasion, we focused on the following three basic design aims.
The first was to make the size of the software (mailer) for handling electronic mail small. For that reason, we divided the functions necessary for a mailer and adopted an architecture in which the mailer is organized from single-function "micro-applications."
The second was for the OS to manage in one bundle all common settings for the mailer on the Internet--such as the user's mail address, the address of the mailer server, the account name, etc.--rather than have the mailer itself manage them, as is the case at present.
The third was to provide a user interface based on the real object/virtual object filing model of the BTRON-specification operating system.
Scaling Down and Collaborative Operation of the Mailer
Because the mailers that are being marketed at present realize all their functions in a single piece of software, they are extremely large in size. For that reason, even if one would simply like to browse through some mail, he/she has to wait listening to crunching noises until a giant piece of software starts up.
Because mailers are such large pieces of software, their reliability also becomes exceedingly low, and there are even ones run wild.
Furthermore, in the manner that some software has good functions for sorting mail, but IMAP [1] is supported with different software, it is often the case that users are troubled by the good and bad merits of the ease of use of each function.
[1] IMAP (Internet Message Access Protocol)
IMAP is a higher level protocol than POP through which an electronic mail application (the client, the mailer) dynamically connects to a mail server and takes out messages. The latest version is IMAP4 (1996, RFC2060). With IMAP, the client can do keyword searches of messages on the server, and it is possible to specify which messages should or should not be downloaded. IMAP was created at Stanford University.
Accordingly, the BTRON mailer software was realized by breaking down the mailer into parts for each function. This is something that is based on the basic BTRON concept of dividing into independent "micro-applications" by having the individual functions collaborate with each other. With the mailer at this time, we decided to design in keeping with this concept.
In concrete terms, we organized the mailer from the micro-applications in Fig. 1.
Each application respectively provides a single function. The application for transmitting e-mail solely provides only a simple function just for transmitting electronic mail. The result of this is that it is possible to reduce the startup time of the electronic-related application, and thus irritation on the part of the user is eliminated. Moreover, the flexibility of the mailer functions is increased, and it also becomes possible for the user to execute by freely combining the electronic mail transmission program and reception program he/she would like to use.
Furthermore, there is also the merit that in case the user would like a new function, such as an electronic mail sorting function, or automatic distribution or encoding, such a new function can be added to one's mailer if one is willing to make--or purchase--the corresponding single function application.
Making Common Settings for Non-Application-Dependent Settings
With the mailers being marketed at present, one carries out the SMTP [3] sever and POP server [4] settings for every software application. For this reason, making the exact same settings in multiple software applications often occurs. For example, when software applications are changed, one ends up having to redo the exact same settings. This is troublesome.]
[2] SMTP (Simple Mail Transfer Protocol)
SMTP (1982, RFC821) is the standard protocol for exchanging electronic mail messages between electronic mail servers on the Internet. A SMTP server is an electronic mail server that supports SMTP.
[3] POP (Post Office Protocol)
POP is a simple protocol through which an electronic mail application (the client, the mailer) dynamically connects to a mail server and takes out messages. There are two versions, POP2 (1985, RFC937) and POP3 (1996, RFC1939); at present, POP3 is becoming the standard. Generally, when the mailer takes out a message, the message on the server is erased.
Accordingly, we think we should try to avoid the troublesomeness of settings by bringing to the OS settings that do not rely on applications or other software.
In browsers and electronic mail transmission and reception, things such as the name of the server, one's mail address, and so on are not things that change according to the application or other software. For that reason, we decided to manage these settings with a common settings file called NETCONFPLUS, and thus these settings are shared by each application.
As long as applications share the NETCONFPLUS common settings file, even when we change applications, the settings carried out with the previous application can be made use of without any changes also by the next application.
Interface Based on the Real Object/Virtual Object Model
What we call the real object/virtual object model is a fundamental idea of TRON. Even in electronic mail software, we provide the interface in a manner that makes it possible to handle electronic mail as virtual objects. As a result of this, it is possible to handle electronic mail with the same feeling as other BTRON software developed to date.
Here I shall explain the functions of the applications that were actually created based on the ideas discussed in the previous section.
Creating and Writing the Electronic Mail Document
In accordance with the micro-application concept, this was omitted from the basic components of the electronic mail. If you ask why, this is because a document that is created is sent to an electronic mail transmission server, and then for the first time that document becomes electronic mail--up to that point, it is to the last a "document." The "basic text editor" is already provided as an application at the system level for creating and editing documents; in the creation of mail, there is nothing that cannot be done with the "basic text editor." Accordingly, for creating and editing mail documents, we decided to use the existing "basic text editor."
Application for Sending Electronic Mail
That which possesses the functions to forward a document created with the basic text editor to the electronic mail transmission server and send it to a transmission address is the application for sending electronic mail. When one starts up the application for sending electronic mail, a "mailbox" appears (Fig. 2). This can be thought of as the virtual object of the SMTP server. By dragging the document virtual object to the "mailbox"--in other words, the SMTP server virtual object--the mail gets sent. This is the application of the network real object/virtual object model to electronic mail transmission.
After one drags the electronic mail virtual object to the "mailbox," inputs the address and the title, and pushes the "Send" button, the electronic mail document is actually sent (Figs. 3, 4). Also, in case one adds a header at the beginning of the document that displays the address and the title during the editing of the electronic mail document, the application for sending electronic mail interprets this header and displays an input screen into which the address and title are already entered. By pushing the "Send" button after confirming this, the electronic mail document is sent. This header interpreting function is a function we realized for collaborating with the application for replying to electronic mail, which will be described below.
Application for Receiving Electronic Mail
That which displays electronic mail documents that have been sent is the application for receiving electronic mail. When one starts up the application for receiving electronic mail, electronic mail documents that have been received (received mail) are displayed with virtual objects (Fig. 5). This corresponds to a state in which one has opened virtual objects to the electronic mail reception server. Since what is displayed are virtual objects, if one double clicks them in the same manner as ordinary virtual objects, the basic text editor starts up, and the contents can be viewed (Fig. 6); and if one drags the virtual object to another window, it is copied. Because displaying the mail text is not related to electronic mail reception, we utilize the existing basic text editor.
Furthermore, in the case of electronic mail, the date and time received, the origin of the transmission, etc., are things we would like to know without opening them one by one. For this reason, the received mail list is in the form of a special virtual object list; it is made up so that in addition to the title that shows the name of the virtual object, the date received and origin of the transmission are displayed.
Application for Returning Electronic Mail
If we exclude reading off the transmission source and title data from the received mail and sending back a response to the party concerned, what we can refer to as replying to electronic mail is no different from the editing of a document. For that reason, in the application for creating an electronic mail reply, we only create a minimum template as the return document with the return mail address, title, and quoted text of the other party (Figs. 7, 8); after that, it is possible to freely edit with the basic text editor (Fig. 9). The edited document can then be sent using the same method as a newly created electronic mail document, namely, by dragging the virtual object of the document to the "mailbox" of the application for sending electronic mail (Fig. 10).
The above article on Electronic Mail for BTRON appeared on pages 38-42 in Vol. 55 of TRONWARE . It was translated and loaded onto this Web page with the permission of Personal Media Corporation.
Copyright © 1999 Personal Media Corporation
Copyright © 1999 Sakamura Laboratory, University Museum, University of Tokyo