<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-BA7B9BA6-B840-5182-90B0-A4914592A40D" xml:lang="en"><title>SendAs

Server</title><shortdesc>This section provides detailed description of the SendAs Server

functions and how the SendAs Server processes the client request. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<section><title>SendAs Server process and data flow</title> <p>The following

figure details the processes and data flow with SendAs Server. </p> <fig id="GUID-644B137D-D8A4-514F-9D3F-238CC69C751E">

<title>              SendAs Server process and data flow            </title>

<image href="GUID-AE8D314A-5381-5576-9B17-94BA029A7FEA_d0e500281_href.jpg" placement="inline"/>

</fig> </section>

<section><title>SendAs Server functionality</title> <p>The following sections

give detailed information about the SendAs sever functionality: </p> <p><b>Creating

a SendAs message</b> </p> <p>Client applications can create a message of a

given type that supports SendAs only in the Drafts folder of the message store.

It uses <xref href="GUID-4499491F-FA1A-38E1-BB13-1AB184A31DA6.dita#GUID-4499491F-FA1A-38E1-BB13-1AB184A31DA6/GUID-C7CD5EC4-14EE-3375-BEA0-C7FD273C2574"><apiname>RSendAsMessage::Create()</apiname></xref> to create the message.

An MTM can specify its support of SendAs for a message type in the following

two ways: </p> <ul>

<li id="GUID-E25A3621-D706-5016-9F94-AE823C597AD7"><p>The message type can

set the <xref href="GUID-7D5C9320-17AB-381E-8369-1804EB143199.dita#GUID-7D5C9320-17AB-381E-8369-1804EB143199/GUID-4EDB6002-8750-3E7D-AC60-BFD2BD441E69"><apiname>MTM_CAPABILITIES::send_capability</apiname></xref> resource in its

resource file. This allows the Message Server to know whether the message

type supports SendAs without loading its MTMs. </p> </li>

<li id="GUID-1663559F-C4CE-5B40-848C-B312E60FD8A0"><p>If the MTM does not

declare whether it supports SendAs in its resource file, the Message Server

loads the MTM and queries if it supports the <xref href="GUID-AB92627B-67B0-39AC-9B00-854EA1589B35.dita"><apiname>KUidMtmQueryCanSendMsg</apiname></xref> capability. </p> </li>

</ul> <p><b>Modifying a SendAs message</b> </p> <p>Client applications can

modify a message created by the <xref href="GUID-4499491F-FA1A-38E1-BB13-1AB184A31DA6.dita#GUID-4499491F-FA1A-38E1-BB13-1AB184A31DA6/GUID-C7CD5EC4-14EE-3375-BEA0-C7FD273C2574"><apiname>RSendAsMessage::Create()</apiname></xref> method.

After sending the request, client applications can no longer modify the message.

They can add the following message parts, if supported by the message type. </p> <ul>

<li id="GUID-C84B4945-0E7A-5309-94FF-B849D16F11B7"><p>Body text </p> </li>

<li id="GUID-169AEA41-8650-5BE4-8386-36DD3BE1215B"><p>Attachment </p> </li>

<li id="GUID-EA862642-6FD7-5248-B7ED-6981AB73CA69"><p>BIO type </p> </li>

<li id="GUID-BF7BDB3F-5EAA-565B-8238-3F34E4608222"><p>Recipients—address,

alias and type. For example, To, Cc or Bcc. </p> </li>

<li id="GUID-9509C4D9-A1B1-5C9D-9890-AEBA109ECA0A"><p>Subject </p> </li>

</ul> <p><b>Sending a SendAs Message </b> </p> <p>When a client application

requests to send a message, it must specify whether SendAs must get confirmation

from the user to send the message or not. </p> <p>If a client application

that requests a unconfirmed send is not trusted with the capabilities specified

by the Server MTM of the given message type, the SendAs Server automatically

performs a confirmed send. </p> <p>For a confirmed send, the SendAs Server

uses the UI MTM for the message type to confirm the send request by querying

the phone user. If the send is confirmed by the phone user, the SendAs Server

moves the message to Outbox and sends the message. If the send is refused,

then the message remains in the Drafts folder and the Send-As Server fails

the send request. </p> <p>After the message send is initiated, the Server

MTM for the message type takes responsibility of the message. For successful

and unsuccessful sends, the Server MTM decides to which folder the message

must be moved to. It also governs the rescheduling policy for a failed send

request. </p> <p>A client application can obtain progress for both types of

send requests. Any failures associated with the send are reported back to

the client application through this progress information. The progress information

also provides a send state. For example, message waiting to be sent, sending,

message sent, or message send failed. </p> <p><b>Launching an editor for a

message type</b> </p> <p>The SendAs Server allows client applications to launch

an editor for a specified message type that supports SendAs. After creating

a message, a client application can request to launch the appropriate editor.

It can launch the editor in two ways: a fire-and-forget launch or a launch

and wait. With the fire-and-forget launch, the client application is not notified

when an editor is closed. The launch and wait notifies the client application

when an editor closes. </p> <p>After the editor is launched, the SendAs Server

is no longer responsible for that message, the editor takes the responsibility.

The message editors are applications that are trusted with the required capabilities

to modify and send messages of that type. They communicate directly with the

Message Server using the Message Server APIs. </p> <p><b>Querying the message

type registry</b> </p> <p>The SendAs Server provides several APIs to allow

client applications to query the message type registry. The following are

the available queries: </p> <ul>

<li id="GUID-51165376-26AF-524E-8BA8-B4EFC0C1716D"><p>List the registered

message types that support a specified set of message capabilities. For example,

amount of body text allowed, attachments supported and so on. </p> </li>

<li id="GUID-E875CF63-B35F-581B-A8AE-A04E15A356CE"><p>Obtain the available

account names for a specified message type </p> </li>

<li id="GUID-EBE65718-F480-5840-8A89-A47C099021E3"><p>Get the localised human

readable name for a specified message type that supports SendAs. </p> </li>

</ul><note> Message types that have no accounts or invalid accounts are not

listed. Validation is done by SendAs querying whether the UI MTM supports

validation of the accounts. If the UI MTM does not support validation, all

accounts are assumed to be valid. If the UI MTM supports the verification,

then the list of service IDs is passed to <xref href="GUID-1471F3BD-21BF-3600-BEA2-F3B2C6DC4FFB.dita"><apiname>InvokeSyncFunctionL</apiname></xref> using

the <xref href="GUID-EFB2418B-F3A9-3BF6-90D2-22985845EAAE.dita"><apiname>KMtmUiFunctionValidateService</apiname></xref> command.</note> <p>The

SendAs Server allows client applications only to query the message type registry

about message types that support SendAs. Other message types are ignored. </p> </section>

</conbody><related-links>

<link href="GUID-B015C4A3-469E-5AC4-B9B9-A24AF7444E65.dita"><linktext>SendAs Overview</linktext>

</link>

</related-links></concept>