<?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 xml:lang="en" id="GUID-4CD6C5CC-A91B-56BE-825F-5B10B63627DA"><title>Handling Client Requests</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>The main purpose of the Message Server is to accept and handle requests from clients, which include client applications, Client MTMs, and User Interface (UI) MTMs. These requests include changing the structure or contents of the local folders, sending and receiving messages through different services, changing the contents or structure of remote mailboxes, and MTM-specific requests. </p> <p>Some asynchronous requests can take considerable time to complete. In order to be responsive, message client applications may need to change the context (the message entry being operated on by an instance of <xref href="GUID-85BBE389-81F7-3E2F-A789-446D9BE2CC49.dita"><apiname>CMsvEntry</apiname></xref>) while a request is being processed. To allow this to happen, the request functions return an active object, called an operation object, with base class <xref href="GUID-AF724192-6580-3DE3-9287-3A005C0AA932.dita"><apiname>CMsvOperation</apiname></xref>, which is responsible for handling the request. The client can change the context and use the operation active object to wait for the request to complete. Additionally, the operation class supports a progress function which returns an MTM-specific progress descriptor. The descriptor might contain information such as the number of pages that have been sent so far. UI MTMs can implement a function to display this progress information to the phone user. After the client is notified about the completion of the request, it can check the final progress information, before deleting the operation object. </p> <p>For each request that the Message Server receives, it creates an operation object of its own. This object checks to see if a Server MTM is required to handle the request and, if so, calls the server-side registry to create it. The operation object then calls the appropriate function on the MTM object, which carries out the request asynchronously. While this is happening, the Message Server may receive further requests that require the same Server MTM. The Message Server queues such requests and passes them to the MTM object consecutively. More than one instance of a Server MTM may exist if operations are being called on a different services. </p> </conbody></concept>