This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

A struct (handle to be added, handle of contact requesting the change, reason code, optional message) representing a contact whose attempt to join a group is to be confirmed by the local user, as returned by GetLocalPendingMembersWithInfo on the Group interface. An array of contact handles to invite to the channel A string message, which can be blank if desired

Invite all the given contacts into the channel, or accept requests for channel membership for contacts on the pending local list.

A message may be provided along with the request, which will be sent to the server if supported. See the CHANNEL_GROUP_FLAG_MESSAGE_ADD and CHANNEL_GROUP_FLAG_MESSAGE_ACCEPT flags to see in which cases this message should be provided.

array of handles of current members array of handles of local pending members array of handles of remote pending members Returns arrays of all current, local and remote pending channel members.

The AddMembers method can be used to add or invite members who are not already in the local pending list (which is always valid). The RemoveMembers method can be used to remove channel members (removing those on the pending local list is always valid). The RemoveMembers method can be used on people on the remote pending list. A message may be sent to the server when calling AddMembers on contacts who are not currently pending members. A message may be sent to the server when calling RemoveMembers on contacts who are currently channel members. A message may be sent to the server when calling AddMembers on contacts who are locally pending. A message may be sent to the server when calling RemoveMembers on contacts who are locally pending. A message may be sent to the server when calling RemoveMembers on contacts who are remote pending.

The members of this group have handles which are specific to this channel, and are not valid as general-purpose handles on the connection. Depending on the channel, it may be possible to call GetHandleOwners to find the owners of these handles, which should be done if you wish to eg subscribe to the contact's presence.

Connection managers must ensure that any given handle is not simultaneously a general-purpose handle and a channel-specific handle.

Placing a contact in multiple groups of this type is not allowed and will raise NotAvailable (on services where contacts may only be in one user-defined group, user-defined groups will have this flag). In rooms with channel specific handles (ie Channel_Specific_Handles flag is set), this flag indicates that none of the handle owners are available, and that GetHandleOwners method will always return 0 for channel members other than the self handle. The bitwise OR of zero or more values from ChannelGroupFlags Returns an integer representing the bitwise-OR of flags on this channel. The user interface can use this to present information about which operations are currently valid.

A list of integer handles representing members of the channel An array of integer handles representing the owner handles of the given room members, in the same order, or 0 if the owner is not available If the CHANNEL_GROUP_FLAG_CHANNEL_SPECIFIC_HANDLES flag is set on the channel, then the handles of the group members are specific to this channel, and are not meaningful in a connection-wide context such as contact lists. This method allows you to find the owner of the handle if it can be discovered in this channel, or 0 if the owner is not available.

This channel doesn't have the CHANNEL_SPECIFIC_HANDLES flag, so handles in this channel are globally meaningful and calling this method is not necessary One of the given handles is not a member

Returns an array of handles representing contacts requesting channel membership and awaiting local approval with AddMembers.

Returns an array of structs containing handles representing contacts requesting channel membership and awaiting local approval with AddMembers. An array of structs containing:

A handle representing the contact requesting channel membership
A handle representing the contact making the request, or 0 if unknown
The reason for the request: one of the values of ChannelGroupChangeReason
A string message containing the reason for the request if any (or blank if none)

Returns an array of handles for the members of this channel.

Returns an array of handles representing contacts who have been invited to the channel and are awaiting remote approval.

Returns the handle for the user on this channel (which can also be a local or remote pending member) or 0 if the user not a member at all (which is likely to be the case, for instance, on Type.ContactList channels). Note that this is different from the connection GetSelfHandle on some protocols, so the value of this handle should always be used with the methods of this interface.

A bitwise OR of the flags which have been set A bitwise OR of the flags which have been cleared Emitted when the flags as returned by GetGroupFlags are changed. The user interface should be updated as appropriate. No reason was provided for this change. The change is due to a user going offline. Also used when user is already offline, but this wasn't known previously. The change is due to a kick operation. The change is due to a busy indication. The change is due to an invitation. The change is due to a kick+ban operation. The change is due to an error occurring. The change is because the requested contact does not exist. The change is because the requested contact did not respond. The change is because a contact's unique identifier changed. There must be exactly one handle in the removed set and exactly one handle in one of the added sets. The Renamed signal on the Renaming interface will have been emitted for the same handles, shortly before this MembersChanged signal is emitted. The change is because there was no permission to contact the requested handle.

If members are removed with this reason code, the change is because the group has split into unconnected parts which can only communicate within themselves (e.g. netsplits on IRC use this reason code).

If members are added with this reason code, the change is because unconnected parts of the group have rejoined. If this channel carries messages (e.g. Text or Tubes channels) applications must assume that the contacts being added are likely to have missed some messages as a result of the separation, and that the contacts in the group are likely to have missed some messages from the contacts being added.

Note that from the added contacts' perspective, they have been in the group all along, and the contacts we indicate to be in the group (including the local user) have just rejoined the group with reason Separated. Application protocols in Tubes should be prepared to cope with this situation.

A string message from the server, or blank if not A list of members added to the channel A list of members removed from the channel A list of members who are pending local approval A list of members who are pending remote approval The contact handle of the person who made the change, or 0 if not known A reason for the change: one of the values of ChannelGroupChangeReason Emitted when contacts join any of the three lists (members, local pending or remote pending). Contacts are listed in the removed list when they leave any of the three lists. There may also be a message from the server regarding this change, which may be displayed to the user if desired. An array of contact handles to remove from the channel A string message, which can be blank if desired Requests the removal of contacts from a channel, reject their request for channel membership on the pending local list, or rescind their invitation on the pending remote list. A message may be provided along with the request, which will be sent to the server if supported. See the CHANNEL_GROUP_FLAG_MESSAGE_REMOVE, CHANNEL_GROUP_FLAG_MESSAGE_REJECT and CHANNEL_GROUP_FLAG_MESSAGE_RESCIND flags to see in which cases this message should be provided.

An array of contact handles to remove from the channel A string message, which can be blank if desired A reason for the change: one of the values of ChannelGroupChangeReason As RemoveMembers, but a reason code may be provided where appropriate. The reason code may be ignored if the underlying protocol is unable to represent the given reason.

The provided reason code was invalid.

Interface for channels which have multiple members, and where the members of the channel can change during its lifetime. Your presence in the channel cannot be presumed by the channel's existence (for example, a channel you may request membership of but your request may not be granted).

This interface implements three lists: a list of current members, and two lists of local pending and remote pending members. Contacts on the remote pending list have been invited to the channel, but the remote user has not accepted the invitation. Contacts on the local pending list have requested membership of the channel, but the local user of the framework must accept their request before they may join. A single contact should never appear on more than one of the three lists. The lists are empty when the channel is created, and the MembersChanged signal should be emitted when information is retrieved from the server, or changes occur.

Addition of members to the channel may be requested by using AddMembers. If remote acknowledgement is required, use of the AddMembers method will cause users to appear on the remote pending list. If no acknowledgement is required, AddMembers will add contacts to the member list directly. If a contact is awaiting authorisation on the local pending list, AddMembers will grant their membership request.

Removal of contacts from the channel may be requested by using RemoveMembers. If a contact is awaiting authorisation on the local pending list, RemoveMembers will refuse their membership request. If a contact is on the remote pending list but has not yet accepted the invitation, RemoveMembers will rescind the request if possible.

It should not be presumed that the requester of a channel implementing this interface is immediately granted membership, or indeed that they are a member at all, unless they appear in the list. They may, for instance, be placed into the remote pending list until a connection has been established or the request acknowledged remotely.

If the local user joins a Group channel whose members or other state cannot be discovered until the user joins (e.g. many chat room implementations), the connection manager should ensure that the channel is, as far as possible, in a consistent state before adding the local contact to the members set; until this happens, the local contact should be in the remote-pending set. For instance, if the connection manager queries the server to find out the initial members list for the channel, it should leave the local contact in the remote-pending set until it has finished receiving the initial members list.

If the protocol provides no reliable way to tell whether the complete initial members list has been received yet, the connection manager should make a best-effort attempt to wait for the full list (in the worst case, waiting for a suitable arbitrary timeout) rather than requiring user interfaces to do so on its behalf.