Calendar:Feature Implementations:Emailing Events

<<Back to Features

Use Cases

• User would like to invite people to an event using our attendees button and their email
• Users will want to accept/send invitations when running Sunbird but will expect that to be done via their usual mail client (i.e. not Thunderbird)
• Users of Lightning will expect to use Thunderbird to accept/send invitations
• Users will want to send email alarm reminders to an email-enabled hand-held or portable.

The Interface

Email capabilities are key in order to allow a calendar user to collaborate with other users by sending and receiving event invitations. Both Sunbird and Lightning need this ability. In Sunbird, the email functionality should be supplied by the user-selected email client on the system (this will usually be the default email client on the system).

Note that email interfaces are not the same as SMS interfaces. While they logically could be grouped together under a common "send" framework, this proposal only addresses email interfaces. For the moment it will be assumed that SMS sending will be addressed in its own interface. But, if people want to make an argument that it should be included here, and this interface should be more generalized, I'd be happy to hear it.

Furthermore, as you can see from the above use cases, there is no need for sending an email without a text/calendar mime-encoded ICS attachment. Therefore, in our calendar Email Interface, the email command includes this parameter. That parameter could be specified as NULL which would cause an email to be sent without any text/calendar attachment.

The email properties will probably be used from a "configuration" screen in preferences. I imagine this will be something that will be needed in Sunbird. I do not see a need for such a UI in Lightning where all of that information can be controlled via Thunderbird's Account Settings panel.

/**
 * Sends an email to the recipients using the specified subject and body.
 * If a calIItipItem is attached, then those an ICS representation of those
 * objects are generated and attached to the email. If the calIItipItem is null,
 * then an email is sent without any text/calendar attachments.
 * in parameter: PRUint32 count - size of recipient array
 * in parameter: calIAttendee array of recipients
 * in parameter: AUTF8String subject of email
 * in parameter: AUTF8String body of email
 * in parameter: calIItipItem a set of calIItems encapsulated as calIItipItems.
 */
void sendEmail(in PRUint32 count, 
               [array, size_is(count)] in calIAttendee recipientArray,
               in AUTF8String subject,
               in AUTF8String body,
               in calIItipItem item);

/**
 * Checks the configured default email source, and finds any messages 
 * with text/calendar mime parts that are younger than the specified date.
 * It returns the items it finds in a calIItipItem object.
 * NOTE: In Lightning this will be unimplemented since Thunderbird handles
 * checking email for us.
 * in parameter calIDateTime - only finds emails received since this date.
 * returns calIItipItem 
 */
calIItipItem checkEmail(in calIDateTime dateCutoff);

/**
 * From Email Attribute - used to set the "From Address" on the email.
 * TODO: Do we want this to be readonly?
 */
 attribute AUTF8String senderAddress;

/**
 * Some system specific identifier to let us know what account to use in the
 * system mailer. 
 * TODO: Is this needed or useful?
 */
 attribute AUTF8String emailAccountID;

/**
 * The application name that we will use to send email.
 */
 attribute AUTF8String emailApplicationName;

/**
 * Address for the email server that receives email (i.e. imap or pop server). 
 * This is probably unneeded since the email application should handle this
 * information for us and we should never need to know it. 
 * TODO: Perform further research to determine if this can be removed.
 * TODO: If it is not removed, should it be a network URI? i.e. nsIURI?
 */
 attribute AUTF8String emailIncomingServer;

/**
 * Address for the outgoing (SMTP) server. Again, same caveats here as for the
 * incoming server above.
 * TODO: Perform further research to determine if this can be removed.
 * TODO: If it is not removed,  should it be a network URI? i.e. nsIURI?
 */
 attribute AUTF8String emailOutgoingServer;