diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-93221B70-EB36-5E8E-AE23-700988D5DACB.dita --- a/Symbian3/PDK/Source/GUID-93221B70-EB36-5E8E-AE23-700988D5DACB.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-93221B70-EB36-5E8E-AE23-700988D5DACB.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,90 +1,90 @@ - - - - - -Bearer -Mobility Policy Plug-in -

The bearer mobility policy plug-in enables email server MTMs (POP3, IMAP4, -or SMTP) to do the following tasks, provided bearer mobility is set at the -client-side:

- -

The bearer mobility policy plug-in interface allows customisation of the -migration behaviour of email accounts. It consists of an ECOM interface class, CImMobilityPolicyPlugin and -a call-back class, MImMobilityPolicyHandler which allows -the plug-in to issue policy decisions on individual mobility events.

-
Description

There are two components (APIs) in -the bearer mobility policy plug-in: policy plug-in and policy handler. -A default policy plug-in implementation is provided, which can be overridden.

The -policy handler can set policies on for the preferred bearer to accept or reject, -when the bearer is available. Based on the policy that you set, the migration -to the preferred bearer is decided. If you have set the policy to accept the -preferred bearer, then the policy plug-in receives notification when a switch -to a new bearer occurs, or when the current connection is lost. For graphical -illustration of the architecture, see Architecture.

-
API overview

The CImMobilityPolicyPlugin class -allows the plug-in to be notified about mobility events. The mobility manager -and server MTMs do not attempt to perform a migration until the policy plug-in -has issued a response to a notification.

The MImMobilityPolicyHandler class -allows the bearer mobility policy plug-in to provide the decision on whether -to accept or reject a migration.

The bearer mobility policy -plug-in (CImMobilityPolicyPlugin) implements the following -functions:

    -
  • PreferredCarrierAvailable()

  • -
  • Cancel()

  • -
  • MigrationComplete()

  • -

Responses to the preferred carrier interface are made -through the MImMobilityPolicyHandler class, which has the -following functions:

    -
  • AcceptNewCarrier()

    If -a migration is accepted, this function provides the following options for -managing client-requested operations that may be in progress.

      -
    • The client-requested -operation is immediately stopped the current outstanding server command is -cancelled. The open sockets are closed, and migration is initiated.

    • -
    • The client-requested -operation continues until the data does not need to be re-sent or re-received -after migration. For example, if fetching several messages, the current message -will be allowed to complete.

    • -
    • The client-requested -operation is allowed complete before migration is accepted.

    • -
  • -
  • IgnoreNewCarrier()

  • -
- Bearer plug-in class diagram - -
-
See also
    -
  • For tasks on notifications -using the CImMobilityPolicyPlugin class, see the following:

      -
    • Notifying -the Availability of a Preferred Bearer

    • -
    • Notifying -on Completion of a Bearer Migration

    • -
  • -
  • For tasks on handling -bearer mobility using the MImMobilityPolicyHandler class, -see the following:

      -
    • Accepting -a Newly-Available Bearer

    • -
    • Rejecting -the Newly-Available Bearer

    • -
  • -
+ + + + + +Bearer +Mobility Policy Plug-in +

The bearer mobility policy plug-in enables email server MTMs (POP3, IMAP4, +or SMTP) to do the following tasks, provided bearer mobility is set at the +client-side:

+
    +
  • Check for the bearer +that is currently available.

  • +
  • Register for notifications +when a new bearer becomes available.

  • +
  • Handle notifications +of availability of new bearers, and respond with acceptance or rejection of +the new bearer.

  • +
  • Handle notifications +that a bearer change has occurred, and initiate socket re-establishment.

  • +
+

The bearer mobility policy plug-in interface allows customisation of the +migration behaviour of email accounts. It consists of an ECOM interface class, CImMobilityPolicyPlugin and +a call-back class, MImMobilityPolicyHandler which allows +the plug-in to issue policy decisions on individual mobility events.

+
Description

There are two components (APIs) in +the bearer mobility policy plug-in: policy plug-in and policy handler. +A default policy plug-in implementation is provided, which can be overridden.

The +policy handler can set policies on for the preferred bearer to accept or reject, +when the bearer is available. Based on the policy that you set, the migration +to the preferred bearer is decided. If you have set the policy to accept the +preferred bearer, then the policy plug-in receives notification when a switch +to a new bearer occurs, or when the current connection is lost. For graphical +illustration of the architecture, see Architecture.

+
API overview

The CImMobilityPolicyPlugin class +allows the plug-in to be notified about mobility events. The mobility manager +and server MTMs do not attempt to perform a migration until the policy plug-in +has issued a response to a notification.

The MImMobilityPolicyHandler class +allows the bearer mobility policy plug-in to provide the decision on whether +to accept or reject a migration.

The bearer mobility policy +plug-in (CImMobilityPolicyPlugin) implements the following +functions:

    +
  • PreferredCarrierAvailable()

  • +
  • Cancel()

  • +
  • MigrationComplete()

  • +

Responses to the preferred carrier interface are made +through the MImMobilityPolicyHandler class, which has the +following functions:

    +
  • AcceptNewCarrier()

    If +a migration is accepted, this function provides the following options for +managing client-requested operations that may be in progress.

      +
    • The client-requested +operation is immediately stopped the current outstanding server command is +cancelled. The open sockets are closed, and migration is initiated.

    • +
    • The client-requested +operation continues until the data does not need to be re-sent or re-received +after migration. For example, if fetching several messages, the current message +will be allowed to complete.

    • +
    • The client-requested +operation is allowed complete before migration is accepted.

    • +
  • +
  • IgnoreNewCarrier()

  • +
+ Bearer plug-in class diagram + +
+
See also
    +
  • For tasks on notifications +using the CImMobilityPolicyPlugin class, see the following:

      +
    • Notifying +the Availability of a Preferred Bearer

    • +
    • Notifying +on Completion of a Bearer Migration

    • +
  • +
  • For tasks on handling +bearer mobility using the MImMobilityPolicyHandler class, +see the following:

      +
    • Accepting +a Newly-Available Bearer

    • +
    • Rejecting +the Newly-Available Bearer

    • +
  • +
\ No newline at end of file