/usr/include/telepathy-1.0/rtcom-telepathy-glib/

/* Generated from RTCom telepathy-glib extensions



 */

#ifdef __cplusplus
extern "C" {
#endif

/**
 *
RTComTpContactInfoFlag:
 * @RTCOM_TP_CONTACT_INFO_FLAG_CAN_SET: <![CDATA[           Indicates that SetContactInfo is           supported on this connection.         ]]>
 * @RTCOM_TP_CONTACT_INFO_FLAG_PUSH: <![CDATA[           Indicates that the protocol pushes all contacts' information to the           connection manager without prompting. If set,           RequestContactInfo will not cause a           network roundtrip and           ContactInfoChanged will be emitted           whenever contacts' information changes.         ]]>
 *
 * <![CDATA[         Flags defining the behaviour of contact information on this protocol.         Some protocols provide no information on contacts without an explicit         request; others always push information to the connection manager as         and when it changes.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_CONTACT_INFO_FLAG_CAN_SET = 1,
    RTCOM_TP_CONTACT_INFO_FLAG_PUSH = 2,
} RTComTpContactInfoFlag;

/**
 * NUM_RTCOM_TP_CONTACT_INFO_FLAGS:
 *
 * 1 higher than the highest valid value of #RTComTpContactInfoFlag.
 */
#define NUM_RTCOM_TP_CONTACT_INFO_FLAGS (2+1)

/**
 *
RTComTpContactInfoFieldFlags:
 * @RTCOM_TP_CONTACT_INFO_FIELD_FLAG_PARAMETERS_MANDATORY: <![CDATA[           If present, exactly the parameters indicated must be set on this             field; in the case of an empty list of parameters, this implies that             parameters may not be used.            If absent, and the list of allowed parameters is non-empty,             any (possibly empty) subset of that list may be             used.            If absent, and the list of allowed parameters is empty,             any parameters may be used.         ]]>
 *
 * <![CDATA[         Flags describing the behaviour of a vCard field.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_CONTACT_INFO_FIELD_FLAG_PARAMETERS_MANDATORY = 1,
} RTComTpContactInfoFieldFlags;

/**
 *
RTComTpChannelContactSearchState:
 * @RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_NOT_STARTED: <![CDATA[The search has not started]]>
 * @RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_IN_PROGRESS: <![CDATA[The search is in progress]]>
 * @RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_MORE_AVAILABLE: <![CDATA[The search has paused, but more results can be retrieved           by calling More.]]>
 * @RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_COMPLETED: <![CDATA[The search has been completed]]>
 * @RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_FAILED: <![CDATA[The search has failed]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_NOT_STARTED = 0,
    RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_IN_PROGRESS = 1,
    RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_MORE_AVAILABLE = 2,
    RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_COMPLETED = 3,
    RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATE_FAILED = 4,
} RTComTpChannelContactSearchState;

/**
 * NUM_RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATES:
 *
 * 1 higher than the highest valid value of #RTComTpChannelContactSearchState.
 */
#define NUM_RTCOM_TP_CHANNEL_CONTACT_SEARCH_STATES (4+1)

/**
 *
RTComTpLocalHoldState:
 * @RTCOM_TP_LOCAL_HOLD_STATE_UNHELD: <![CDATA[           All streams are unheld (the call is active). New channels SHOULD           have this hold state.         ]]>
 * @RTCOM_TP_LOCAL_HOLD_STATE_HELD: <![CDATA[           All streams are held (the call is on hold)         ]]>
 * @RTCOM_TP_LOCAL_HOLD_STATE_PENDING_HOLD: <![CDATA[           The connection manager is attempting to move to state Held, but           has not yet completed that operation. It is unspecified whether           any, all or none of the streams making up the channel are on hold.         ]]>
 * @RTCOM_TP_LOCAL_HOLD_STATE_PENDING_UNHOLD: <![CDATA[           The connection manager is attempting to move to state Held, but           has not yet completed that operation. It is unspecified whether           any, all or none of the streams making up the channel are on hold.         ]]>
 *
 * <![CDATA[         The hold state of a channel.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_LOCAL_HOLD_STATE_UNHELD = 0,
    RTCOM_TP_LOCAL_HOLD_STATE_HELD = 1,
    RTCOM_TP_LOCAL_HOLD_STATE_PENDING_HOLD = 2,
    RTCOM_TP_LOCAL_HOLD_STATE_PENDING_UNHOLD = 3,
} RTComTpLocalHoldState;

/**
 * NUM_RTCOM_TP_LOCAL_HOLD_STATES:
 *
 * 1 higher than the highest valid value of #RTComTpLocalHoldState.
 */
#define NUM_RTCOM_TP_LOCAL_HOLD_STATES (3+1)

/**
 *
RTComTpLocalHoldStateReason:
 * @RTCOM_TP_LOCAL_HOLD_STATE_REASON_NONE: <![CDATA[           The reason cannot be described by any of the predefined values           (connection managers SHOULD avoid this reason, but clients MUST           handle it gracefully)         ]]>
 * @RTCOM_TP_LOCAL_HOLD_STATE_REASON_REQUESTED: <![CDATA[           The change is in response to a user request         ]]>
 * @RTCOM_TP_LOCAL_HOLD_STATE_REASON_RESOURCE_NOT_AVAILABLE: <![CDATA[           The change is because some resource was not available         ]]>
 *
 * <![CDATA[         The reason for a change to the Local_Hold_State. Clients MUST         treat unknown values as equivalent to Local_Hold_State_Reason_None.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_LOCAL_HOLD_STATE_REASON_NONE = 0,
    RTCOM_TP_LOCAL_HOLD_STATE_REASON_REQUESTED = 1,
    RTCOM_TP_LOCAL_HOLD_STATE_REASON_RESOURCE_NOT_AVAILABLE = 2,
} RTComTpLocalHoldStateReason;

/**
 * NUM_RTCOM_TP_LOCAL_HOLD_STATE_REASONS:
 *
 * 1 higher than the highest valid value of #RTComTpLocalHoldStateReason.
 */
#define NUM_RTCOM_TP_LOCAL_HOLD_STATE_REASONS (2+1)

/**
 *
RTComTpMessagePartSupportFlags:
 * @RTCOM_TP_MESSAGE_PART_SUPPORT_FLAG_ONE_ATTACHMENT: <![CDATA[           SendMessage will accept messages           containing a textual message body,           plus a single attachment of any type listed in the           SupportedContentTypes property. It does not make sense for this           flag to be set if Message_Part_Support_Flag_Data_Only is not also set           (because the connection manager can trivially provide an empty text           part if necessary).         ]]>
 * @RTCOM_TP_MESSAGE_PART_SUPPORT_FLAG_MULTIPLE_ATTACHMENTS: <![CDATA[           SendMessage will accept messages containing a textual message body,           plus an arbitrary number of attachments of any type listed in the           SupportedContentTypes property. It does not make sense for this           flag to be set if Message_Part_Support_Flag_One_Attachment is not           also set.         ]]>
 *
 * <![CDATA[         Flags indicating the level of support for message parts on this           channel. They are designed such that setting more flags always           implies that the channel has more capabilities.          If no flags are set, this indicates that messages may contain           a single message part whose content-type is any of the types           from SupportedContentTypes, possibly with some alternatives.          There is no flag indicating support for alternatives. This is           because the SendMessage implementation can always accept messages           containing alternatives, even if the underlying protocol does not,           by deleting all alternatives except the first (most preferred)           that is supported.                     Each of the flags so far implies the previous flag, so we could           have used a simple enumeration here; however, we've defined           the message-part support indicator as a flag set for future           expansion.                   See SupportedContentTypes for some           examples.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_MESSAGE_PART_SUPPORT_FLAG_ONE_ATTACHMENT = 1,
    RTCOM_TP_MESSAGE_PART_SUPPORT_FLAG_MULTIPLE_ATTACHMENTS = 2,
} RTComTpMessagePartSupportFlags;

/**
 *
RTComTpMessageSendingFlags:
 * @RTCOM_TP_MESSAGE_SENDING_FLAG_REPORT_DELIVERY: <![CDATA[           Provide a successful delivery report if possible, even if this is             not the default for this protocol. Ignored if delivery reports are             not possible on this protocol.                         In some protocols, like XMPP, it is not conventional to request               or send positive delivery notifications.                       Delivery failure reports SHOULD always be sent, but if this flag             is present, the connection manager MAY also try harder to obtain             failed delivery reports or allow them to be matched to outgoing             messages.         ]]>
 *
 * <![CDATA[         Flags altering the way a message is sent. The "most usual" action         should always be to have these flags unset.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_MESSAGE_SENDING_FLAG_REPORT_DELIVERY = 1,
} RTComTpMessageSendingFlags;

/**
 *
RTComTpDeliveryStatus:
 * @RTCOM_TP_DELIVERY_STATUS_UNKNOWN: <![CDATA[           The message's disposition is unknown.           Clients SHOULD consider all messages to have status           Delivery_Status_Unknown unless otherwise specified; connection           managers SHOULD NOT signal this delivery status explicitly.         ]]>
 * @RTCOM_TP_DELIVERY_STATUS_DELIVERED: <![CDATA[           The message has been delivered to the intended recipient.         ]]>
 * @RTCOM_TP_DELIVERY_STATUS_TEMPORARILY_FAILED: <![CDATA[           Delivery of the message has failed. Clients SHOULD notify the user,           but MAY automatically try sending another copy of the message.                         Similar to errors with type="wait" in XMPP; analogous to             4xx errors in SMTP.                    ]]>
 * @RTCOM_TP_DELIVERY_STATUS_PERMANENTLY_FAILED: <![CDATA[           Delivery of the message has failed. Clients SHOULD NOT try again           unless by specific user action. If the user does not modify the           message or alter configuration before re-sending, this error is           likely to happen again.                         Similar to errors with type="cancel", type="modify"             or type="auth" in XMPP; analogous to 5xx errors in SMTP.                    ]]>
 * @RTCOM_TP_DELIVERY_STATUS_ACCEPTED: <![CDATA[           An intermediate server has accepted the message but the message           has not been yet delivered to the ultimate recipient. The           connection manager might send a Failed report or Delivered report           later.                         Similar to "202 Accepted" success code in SIP; analogous to             251 and 252 responses in SMTP.                    ]]>
 *
 * <![CDATA[         The status of a message as indicated by a delivery report.          If this enum is extended in future specifications, this should           only be to add new, non-overlapping conditions (i.e. all failures           should still be signalled as either Temporarily_Failed           or Permanently_Failed). If additional detail is required (e.g.           distinguishing between the various types of permanent failure) this           will be done using additional keys in the Message_Part.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_DELIVERY_STATUS_UNKNOWN = 0,
    RTCOM_TP_DELIVERY_STATUS_DELIVERED = 1,
    RTCOM_TP_DELIVERY_STATUS_TEMPORARILY_FAILED = 2,
    RTCOM_TP_DELIVERY_STATUS_PERMANENTLY_FAILED = 3,
    RTCOM_TP_DELIVERY_STATUS_ACCEPTED = 4,
} RTComTpDeliveryStatus;

/**
 * NUM_RTCOM_TP_DELIVERY_STATUSES:
 *
 * 1 higher than the highest valid value of #RTComTpDeliveryStatus.
 */
#define NUM_RTCOM_TP_DELIVERY_STATUSES (4+1)

/**
 *
RTComTpDeliveryReportingSupportFlags:
 * @RTCOM_TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_FAILURES: <![CDATA[           Clients MAY expect to receive negative delivery reports if           Message_Sending_Flag_Report_Delivery is specified when sending.                         If senders want delivery reports, they should ask for them.             If they don't want delivery reports, they can just ignore them,             so there's no need to have capability discovery for what will             happen if a delivery report isn't requested.                    ]]>
 * @RTCOM_TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_SUCCESSES: <![CDATA[           Clients MAY expect to receive positive delivery reports if           Message_Sending_Flag_Report_Delivery is specified when sending.                         Same rationale as Receive_Failures.                    ]]>
 *
 * <![CDATA[         Flags indicating the level of support for delivery reporting on this         channel. Any future flags added to this set will conform to the         convention that the presence of an extra flag implies that         more operations will succeed.       ]]>
 *
 * Bitfield/set of flags generated from the Telepathy specification.
 */
typedef enum {
    RTCOM_TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_FAILURES = 1,
    RTCOM_TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_SUCCESSES = 2,
} RTComTpDeliveryReportingSupportFlags;


#ifdef __cplusplus
}
#endif
librtcom-telepathy-glib-dev 0.1.38~git.1.e4dae27b-0ubuntu4 / usr / include / telepathy-1.0 / rtcom-telepathy-glib / _gen / enums.h
