Figure 1.1 Messaging Access API Architecture
sendCommand (or pass-through) interface, which programmers can use to send protocol elements that are not directly supported by the API. The IMAP4 API has further conveniences, such as transparently handling unilateral and unsolicited responses from the server and making these available at the API level through a callback mechanism.
For more information about the sendCommand API, see the reference entries for include directory protocol directory include/protocol directory - C header files for the Messaging Access SDK protocol implementationslib directory - Implementation library for each Protocol APIexamples directory - Sample code that demonstrates selected parts of the Messaging Access SDKReadMeC.htm - Links to current installation information, development notes, system requirements, information about using the SDK that may be more current than this guide, and Netscape licensing information.ReadMeC.htm, included in the SDK.
[Top]
| Platforms |
Supported Versions
|
|
|
|
|
|
|
| |
|---|
lptr) that represents client data; this is set in the sink structure by the application. The sink structure is always returned to the application when a callback is are made. typedef struct smtpSink
/* User data. */
void * pOpaqueData;
/* Notification for the response to the connection to the server. */
void (*connect)( smtpSink_t * in_psmtpSink,Each function prototype is a callback that is associated with one or more functions in the SDK implementation of the protocol. Functions with multi-line responses map to more than one callback, as shown in the table for
int in_responseCode,
const char * in_responseMessage );
...
} smtpSink_t;
smtp_expand. The second callback provides a notification that the operation is complete.
| Function |
Callback, Defined in smtpSink_t
smtp_expand void (*expand)(SMTPSinkPtr_t in_psmtpSink, smtp_expand void (*expandComplete)(SMTPSinkPtr_t in_psmtpSink); |
|---|
null, as follows:
smtpSink_t.expand = null;When you start a session with SMTP, IMAP4, or POP3, you first create (initialize) the sink. Then you create the client, which calls the sink functions. The sink receives and processes all the available server response data whenever
processResponses is called. This call reads in responses from the server and invokes the appropriate callback function for all responses that are available at the time of execution.
You can create more than one response sink, based on what you want the messaging application to do. In SMTP, IMAP4, and POP3, you can change the response sink in use with the setResponseSink function.
When you start a session with the MIME dynamic parser, you first create and initialize the data sink, and then you create the parser. The parser makes callbacks to its data sink based on the kind of data it finds in the input stream. For example, if it finds a header, it makes the header callback. For the other protocols, the callback comes from the server and callbacks tend to be tied to individual functions.
For MIME, the kind of callback is dependent upon the kind of data that is in the input stream. There are no particular correspondences between functions and data sink callback prototypes, as there are in the other protocols.
For more information, see the section about implementing the response sink in each of these chapters: Sending Mail with SMTP, Receiving Mail with IMAP4, Receiving Mail with POP3, and Building and Parsing MIME Messages.
NOTE: POP3, IMAP4, and POP3 commands are asynchronous. After sending a command, the application does not have to wait to issue the next one, but can do something else. §[Top]
nsmail.h. For a complete list of SDK error codes, see Error Definitions.
Table 1.2 Messaging Access SDK Errors
NOTE: Error codes and other definitions to apply to all protocols are defined in Shared C Definitions. §[Top]
include directory and a lib directory under the install root.
include directory contains the files nsstream.h and nsmail.h. These are common include files for all of the Protocol APIs. include directory contains a subdirectory named protocol. This subdirectory contains the individual protocol API-specific include files: mime.h, mimeparser.h, smtp.h, pop3.h, and imap4.h. The mime.h file contains definitions common to the MIME encoder and the MIME parser APIs. The mimeparser.h file contains definitions specific to the MIME parser API. <nsmail.h> and <nsstream.h>, along with any Protocol API include files: <mime.h> <mimeparser.h>, <smtp.h>, <pop3.h>, and <imap4.h>, that you need.
The lib directory contains the library files for the different protocol APIs: libmime.*, libsmtp.*, libpop3.*, and libimap4.*. The lib directory also contains the library that is common to all protocol APIs, libcomm.*. Here, the extension * represents the platform-specific extensions for the libraries: .dll or .lib on MS Windows; .so on Solaris and IRIX; .sl on HPUX; and _shr.a on AIX.
The libmime library contains the implementation of the MIME encoder as well as the MIME parser API. You must link with the libmime library if you intend to use the MIME encoder API, the MIME parser API, or both.
[Top] [Compiling with the C SDK]libmime.*, libsmtp.*, libpop3.* , libimap4.* and libcomm.* to your work directory, for example: /usr/lib/msgsdk-L/usr/lib/msgsdk -lmime -lsmtp -lcomm -DXP_UNIX flag in your compilation (cc) step. -lsocket and -lnsl. msgsdk library path in the LD_LIBRARY_PATH (on Solaris) or the equivalent on other platforms. This way, the clients can find the msgsdk shared libraries at run time. libcomm.lib and with one or more of the protocol-specific libraries libmime.lib, libsmtp.lib, libpop3.lib, and libimap4.lib. lib files are located, for example, by using /libpath or by setting the LIB environment variable. -DWIN32 flag in your compilation (cl) step. .dll files to one of these locations: system directory. PATH environment variable. Last Updated: June 3, 1998