Updates a remote entry with relevant data when called by the Message Server.

Implementations should provide this function if the messaging protocol supports updating of remote entries. If this is not supported, implementations should leave with KErrNotSupported.

The Server-side MTM implementation must decide what information in the TMsvEntry is relevant to the remote entry, and translate it appropriately for the specific protocol. Most of the data contained in the TMsvEntry is specific to the Symbian OS Message Server, and would probably have no direct correlation with the protocol's own storage format. Some entry data may however be useful. For example, if the protocol supports remote renaming of folders, the implementation could:

1. check for a folder type entry

2. extract the folder name from aNewEntry.iDetails

3. check if the folder name has changed by comparing the new name with iDetails in the index entry currently; if not, complete with KErrNone

4. initiate a protocol-specific action to rename the remote folder

The implementation should also always update the local Message Server index through CMsvServerEntry::ChangeL().

Tests if the Server-side MTM object should be deleted when called by the Message Server

It is useful to stop the MTM being deleted when more commands are expected shortly. This would be the case, for example, after receiving a command to go online.

If there are no more commands expected by the Server-side MTM object, then the function should return EFalse, and the Message Server will delete it.

Handles the completion of operations in order to migrate. This is called by the PrepareForNewCarrier() function, when it is called by the mobility manager with the mobility action CompleteCurrentOpForMigration.

Copies a selection of entries from a local location to a remote location.

Requirements:

Implementations should provide this function if the messaging protocol supports retrieval of remote entries. If this is not supported, implementations should leave with KErrNotSupported.

Implementations of this function have three fundamental steps:

1. reading entry data

2. converting entry data from the Message Server format into that required by the protocol

3. doing the transfer operation using the appropriate communications protocols

Copies a selection of entries from a remote location to a local location. This will only be meaningful for some protocols.

Requirements:

Implementations should provide this function if the messaging protocol supports retrieval of remote entries. If this is not supported, implementations should leave with KErrNotSupported.

Implementations of this function have three fundamental steps:

1. doing the transfer operation using the appropriate communications protocols

2. converting protocol-specific data into the three-part storage format (index entry, message store, binary files) required by the Message Server

3. updating entries in the Message Server

Copies a selection of entries within a remote location.

Requirements:

Implementations should provide this function if the messaging protocol supports the ability to copy entries within a remote service. If this is not supported, implementations should leave with KErrNotSupported.

Creates a new remote entry with relevant data when called by the Message Server.

Implementations should provide this function if the messaging protocol supports creation of remote entries. If this is not supported, implementations should leave with KErrNotSupported.

As with ChangeL(), the Server-side MTM implementation must decide what information in the TMsvEntry is relevant to the remote entry, and translate it appropriately for the specific protocol. Most of the data contained in the TMsvEntry is specific to the Message Server, and would probably have no direct correlation with the protocol's own storage format. For example, for a folder, probably only the name and parent are needed, so if the protocol supports creation of remote folders, the implementation could:

1. check for a folder type entry

2. get the folder name and parent details from aNewEntry

3. initiate a protocol-specific action to create the remote folder

Deletes each entry in the supplied selection when called by the message Server. If any of the entries in the selection is a parent entry, then all its children should also be deleted, recursively to the bottom of the ownership tree.

Implementations should provide this function if the messaging protocol supports deletion of remote entries. If this is not supported, implementations should leave with KErrNotSupported.

Implements cancellation of an outstanding request.

This function is called as part of the active object's Cancel().

It must call the appropriate cancel function offered by the active object's asynchronous service provider. The asynchronous service provider's cancel is expected to act immediately.

DoCancel() must not wait for event completion; this is handled by Cancel().

CActive::Cancel

Cancel according to iState.iCurrentOperation

If the cancel is to allow a migration, the operation object in use is cancelled, but not deleted. This means it is possible to restart it later.

Called by the base class RunL() if DoRunL() leaves.

It should be implemented to handle this error. For example, progress information could be updated to reflect the problem.

Handles the completion of any asynchronous requests that it makes. It is called from the base class RunL() .

Note that any leaves made by this function result in DoComplete() being called with the leave code.

The extension method provides a polymorphic behaviour to call the correct MTM.

Returns Progress info for Migration purposes

Moves a selection of entries from a remote location to a local location.

Requirements:

Implementations should provide this function if the messaging protocol supports retrieval of remote entries. If this is not supported, implementations should leave with KErrNotSupported.

Implementations of this function have three fundamental steps:

1. doing the transfer operation using the appropriate communications protocols

2. converting protocol-specific data into the three-part storage format (index entry, message store, binary files) required by the Message Server

3. updating entries in the Message Server

MoveToLocalL() should differ from CopyToLocalL() in additionally deleting the original remote data.

Moves a selection of entries within a remote location.

Requirements:

Implementations should provide this function if the messaging protocol supports the ability to move entries within a remote service. If this is not supported, implementations should leave with KErrNotSupported.

The implementation of MoveWithinServiceL() should differ from CopyWithinServiceL() in additionally deleting the original data.

Notice that the New Carrier is now active and the server MTM can make connections on it. Once this notice is received from the Mobility Manager, the Server MTM can create a new session on it and restart any awaiting operations on the New Carrier. These could be operations that were stopped mid-way and need resuming from there or operations(requests) that were cancelled and need starting from beginning.

Notice that a preferred carrier has become available, and migration to that bearer has been accepted. The Pop Server MTM shall either pause or allow any current operation to complete according to the action specified in parameter aAction. Once the current operation is paused or complete, the Pop Server MTM shall close any existing sockets and finally notify the mobility framework that it is ready to migrate to the new carrier.

This function is called by the Message Server to get progress information for the current asynchronous operation.

The call is made as a response to a client program requesting progress information through CMsvOperation::ProgressL(). The packing format used in the TDesC8 is MTM-specific. Only the implementation of the User Interface MTM progress information functions need to understand the format.

The progress buffer should have a maximum size of 256 bytes.

CBaseMtmUi::DisplayProgressSummary() CBaseMtmUi::GetProgress()

Restarts any pre-migration outstanding operations, or set the state machine into the same state it was pre-migration along with any necessary connections and set ups.

Note that iCurrentOperation will have returned to EPopConnectedAndIdle if the migration type was "allow complete" or "stop for migrate" and the operation came to a natural finish.

If iCurrentOperation is not EPopConnectedAndIdle, it indicates that the operation had not completed prior to the migration. This is caused with by an "accept immediately" migration, a CarrierLost() migration, or a "stop operation" migration for which the operation did not come to a natural completion. In these cases, the operation in progress needs to be resumed.

Creates the mobility manager and registers the RConnection for notification of bearer migration events, if the necessary conditions are met.

Returns ETrue if mobility enabled and the initial carrier has been rejected.

Executes an MTM-specific operation on a selection of entries when called by the Message Server.

The call is made as a response to a client program invoking an MTM-specific operation through CBaseMtm::InvokeSyncFunctionL()/InvokeAsyncFunctionL(). The aSelection, aCommand, and aParameter arguments pass the values of the original aSelection, aFunctionId, and aParameter respectively arguments from such a call. The use (if any) of the aSelection and aParameter arguments by the function depends on the command.

Handles the halting of operations in order to migrate. This is called by the PrepareForNewCarrier() function, when it is called by the mobility manager with the mobility action StopCurrentOpForMigration.

Stores configuration to be re-used post Migration.