Called when an abort packet is received from the client.

An OBEX abort command simply cancels the current operation, and does not necessarily have to cause the connection to be dropped. On return, a ERespSuccess packet is sent to the client.

Cancel an asynchronous callback request (ie. PutRequest/GetRequest/PutComplete/GetComplete/SetPath notification).

Note that ignoring this call will lead to a panic when the indication callback function is called.

Called if an OBEX protocol error occurs.

It is only called for fatal errors that cause the OBEX connection to terminate. An error that does not terminate the connection, for example the server issuing a semantically valid, but unrecognised command, will not be indicated.

Called when the final packet of the object has been returned to the client.

Note like PutCompleteIndication(), this function might not be called for each GetRequestIndication(), if the operation is interrupted by an error.

Following this notification, the server will wait for a call to CObexServer::RequestCompleteIndicationCallback supplying a Obex response code.

Called for every packet of get reply sent by the server back to the client.

The function is only called while an object is being sent to the client, not while the client is providing its initial specification for the object it requires.

You can use this function to provide user notification on the object being sent, and its progress. As with PutPacketIndication(), you should consider that this function might get called often, especially for large objects and small OBEX packet sizes, so the speed of execution here is important.

KErrNone to continue sending the object, or any other error code to cancel the operation

Called when a full get request has been received from the client.

aRequestedObject holds all the details about the object the remote client has requested. Use this function to analyse the client's request, and return a pointer to the object to be returned to the client, or NULL to return no object.

Following this notification, the server will wait for a call to CObexServer::RequestIndicationCallback supplying a CObexBaseObject derived object to send to the client or a response code specifying the error.

Returns a null aObject if the extension is not implemented, or a pointer to another interface if it is.

Called when an OBEX connection is made from a remote client.

Override this function to provide any extra OBEX connection processing.

Called on a (graceful) OBEX disconnection by the client.

Override this to provide any extra processing OBEX disconnection processing.

Note that this indication will not be raised if the remote machine simply drops the transport connection. However, ErrorIndication() will be called if the disconnection is unexpected/ invalid (i.e. another operation was in progress at the time). In all cases, TransportDownIndication() will be called.

Called after the final put packet has been successfully received and parsed.

Note that there will not necessarily be a call to this function corresponding to each PutRequestIndication() as, if an error occurs while the put is being carried out, ErrorIndication() will be called instead.

Following this notification, the server will wait for a call to CObexServer::RequestCompleteIndicationCallback supplying a Obex response code.

Called on receipt of every packet of an OBEX PUT operation.

It will always be preceded by a PutRequestIndication(). The object returned by the request indication will be updated to reflect all the information received concerning the object which the client is sending, from packets up to and including the current one.

You can use this function to provide periodic user notification on the progress of the transfer (noting that the Length attribute may take an arbitrary number of packets to become non-zero, and the constraints on its accuracy). Due to the nature of OBEX operations, where any header attribute can be sent at any point in the transfer, this is also a good place to marshal the details of a received object, and possibly prompt for action on the received object (e.g. renaming on filename clashes).

Note that this function could be hit quite heavily, in proportion to the size of the object transferred. Therefore more consideration should be given to the speed of execution of this function than that of the other indications.

KErrNone instructs the server to allow the client to continue the put operation. Any other value cancels the operation with an appropriate OBEX server response code.

Called on receipt of the first packet of a (valid) put request.

It is called before any parsing of the packet is performed, simply to establish whether this server is interested in receiving objects at all.

Following this notification, the server will wait for a call to CObexServer::RequestIndicationCallback supplying a CObexBaseObject derived object to receive into or a response code specifying the error.

Called when an OBEX SETPATH command is received by the server.

Following this notification, the server will wait for a call to CObexServer::RequestCompleteIndicationCallback supplying a Obex response code.

Called when the transport connection is dropped (by either party).

It is called whether the OBEX connection was gracefully disconnected or not. The function is the definitive place for disconnection processing.

Called when the underlying transport connection is made from a remote client to the server.

Note that this does not, however, indicate an OBEX connection has been successfully established.

You can define any low-level connection policy here. It is also a good place to set up the local connection information (CObex::LocalInfo()), if any non-defaults are required.