There are two different approaches to developing an email application in PalmOS. One is the application is split into two parts, one part in the PalmOS device and the other part is on a desktop machine. The part on the desktop machine performs the actual sending and receiving of email, and the part on the PalmOS device simply synchronises the data with the desktop machine.
The other approach is the application completely resides within the PalmOS device. The application performs the sending and receiving of the messages through the modem connected to the device. Such approach allows user to send and receive messages from any place they happen to be.
An example of the first approach is the standard Mail application. The software installed in the PalmOS device lacks SMTP or POP3 supports. It depends on its desktop counterpart to do the actual sending and receiving. Messages written by the user is put into a queue. Upon synchronising with the desktop, the desktop counterpart sends the queued messages and also put received messages into the queue.
However there are some works, such as "Top Gun Postman"[3] that provides SMTP and POP3 supports within the PalmOS device for these softwares. This enables users of the standard Mail application to send and receive directly from their devices.
Examples of the second approach are numerous as they affords the highest mobile flexibility. In particular, "MsgAgent"[6] and "DoodleMail"[7] are very popular clients.
EMSD is layered on top of UDP datagram service offered by the PalmOS' IP stack and as such, is oblivious to the how the IP connectivity is achieved. In other words, whether a direct serial link, a wireline modem or a CDPD modem is used is transparent to the EMSD layer. In fact, much of EMSD development and testing is done over LAN and direct serial links by simply adjusting a few tunable parameters.
Due to the numerous number of email applications available for PalmOS, we are taking a different approach to integrate EMSD to these applications than what we did in WindowsCE case.
We encouraged the developers of the applications to integrate the EMSD technology into their softwares. Due to similarities and familiarities of previous protocols, the developers were able to integrate the EMSD technology within a short period of time.
As of the time of writing, the developers of "Top Gun Postman", "MsgAgent", and "DoodleMail" have successfully integrated the EMSD technology into their softwares. In addition, we are currently in the process of supporting a number of other developers to make the transition to the EMSD technology.
Figure 1 illustrates the components involved as well as the layering of services.
In Figure 1, boxes drawn with "===" represent published interfaces within PalmOS. Each email application contains supports for EMSD. Email applications that do not support transferring messages from within the device is enhanced through another application, like depicted in Figure 2 between the Standard Mail Application and Top Gun Postman. For applications supporting SMTP and POP3 protocols, incorporations of support for the EMSD protocol is easy and fast because the EMSD library complement the existing SMTP and POP3 library within each application.
PalmOS is capable of connecting to the Internet Service Provider using PPP or SLIP or CSLIP protocol. PalmOS does not distingush the medium of the connection. A CDPD modem works as well as wire-based connection such as serial line or phone line.
There are many scenarios in which EMSD can be used to provide messaging services, but for the purposes of this paper, we will consider only the scenario where the following are true:
- Target end user already has an email mailbox.
- The mailbox mentioned is accessible via POP3/SMTP
- The end user would like to be able to access this
mailbox via EMSD
In all cases, the EMSD component on each mail applications in the PalmOS communicates directly with an EMSD Message Transfer Agent (MTA) which functions as a gateway between EMSD and SMTP. In other words, messages exchanged between the PalmOS and the EMSD MTA are in the efficient EMSD format (in the airlink where EMSD's attributes are needed). The EMSD MTA handles translating EMSD format messages to the Internet format (RFC-822)[2] and sending them on, or translating incoming Internet messages destined at the EMSD PalmOS node to EMSD format and handing them over using EMSD protocols.
The EMSD MTA can reside anywhere on the Internet, including the CDPD service provider, at an ISP or as Customer Premise Equipment (CPE) at the customer site. Because EMSD MTAs maintain their own subscriber base, all of the above schemes can be deployed simultaneously. For example, The Neda Customer Premise Message Center was designed as a CPE MTA.
When a user is going mobile, s(he) can initiate forwarding of all or certain classes of messages (for example all URGENT messages) to the assigned EMSD address. A mailbox sorter scheme similar to the "Procmail" utility fits well into this model.
If the system where the user's mailbox resides is EMSD-aware or is the node where the EMSD-MTA entity is running, then a variety of features can be included. An example would be setting up the attributes of EMSD forwarding on the fly and delivering a message to a user only once...
All messages originated from the mobile PalmOS unit would simply be sent via EMSD to the EMSD-MTA without any secondary filter processing. Filter processing at the user mailbox level is relevant only for delivery of messages coming from the Internet destined to the EMSD user.