A dealer asks: I'm thinking of using EMAILX or PDFX for sending emails from a customer's application. What are the economics and advantages of using A-Shell's e-mail capability?

Jack replies:

Operation: You use XCALL EMAILX to send an email from your application, and you get an immediate response code back, since it talks directly to the SMTP server. PDFX/email happens via the XCALL SPOOL interface, and only applies to the document you are printing and converting to PDF.

EMAILX pros/cons: It's unrelated to printing, and allows you to send pretty much any kind of message. You can construct the body using plain text or HTML, and you can add binary (MIME-encoded) attachments at will. You have total control over the headers and can add any kind of header you like. Extensive logging/debugging capabilities (5 levels of verbosity allow you to monitor the entire conversation with the SMTP server if so desired.) The immediate response can be a good thing or a bad thing (good for user feedback in the app, bad if you don't care and just want to queue it.) If your SMTP server requires an SSL (or STARTTLS) login, you'll need a reasonably recent (later 5.1+) version of A-Shell with support for TLS.

PDFX pros/cons: If you just want to email a single PDF document at a time that you are generating via GDI printing, then it is the simplest way to go since it all happens inside the XCALL SPOOL (although you do need to add some additional //PDFX directives to your print file). But it can't send multiple attachments, nor anything but the one PDF that you generated by printing. You can add a text message to the body of the email, but you're limited to plain text. It does support both SMTP-direct and IMAP (sent via your email client), but nowadays Windows and especially Outlook make it very difficult to send via the email client due to security concerns.