[Bug 23148] Telepathy 1.0: break D-Bus API to remove deprecated stuff (metabug)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=23148

--- Comment #23 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
Target_Type
    Enumeration describing the type of entity with which a channel
    communicates.

    For instance, a text chat or VoIP call with a person or automated system
has
    target type "contact", a text chatroom or a VoIP call to a conferencing
    system ideally has target type "room", and a channel listing chatrooms
    available on a server has target type "none".

    None (0)
        The absence of a target, contact, room, etc. For instance,
        _ContactSearch_, _RoomList_, _ServerAuthentication_ and
        _ServerTLSConnection_ channels do not communicate with a specific
        entity, so they have this channel type.

        This channel type is also used for chatrooms that cannot be
        addressed by name (so users cannot join by typing a name or number,
        only by being invited), such as multi-user "switchboards" in MSNP.

        Where this appears alongside a _Handle_ and/or _Identifier_,
        the handle MUST be 0 and the identifier MUST be the empty string.

    Contact (1)
        A contact, i.e. a person or automated system.

        The corresponding identifier is a normalized form of the
        contact's unique machine-readable identifier in this particular
        protocol (such as an XMPP JID, SIP URI, AIM screen-name, ICQ number
        or IRC nickname). For instance, any parts of the identifier
        that are defined to be case-insensitive by the protocol SHOULD
        be normalized to lower-case.

        In protocols where conferencing systems cannot reliably be
        distinguished from individuals, conferencing systems MAY
        also appear with Target_Type_Contact.

        | [rationale]
        | For instance, calls to/from SIP teleconferencing "rooms"
        | typically appear as a simple SIP URI

    Room (2)
        A chatroom or teleconferencing system that can be addressed
        by name.

        The corresponding identifier is a normalized form of the
        room's unique machine-readable identifier in this particular
        protocol, such as the JID "jdev at conference.jabber.org"
        on XMPP, or the channel name "#telepathy" on IRC.

Handle
    An unsigned 32-bit integer representing a string. A handle is
    meaningless on its own, and must be paired with a _Target_Type_.
    Among nonzero handles with the same Target_Type, there is a
    bidirectional mapping between handles and strings.

    The handle 0 is special, and represents the absence of a
    contact, room etc. It corresponds to Target_Type_None.

Contact_Handle
    A nonzero _Handle_ of type _Target_Type_Contact_, or 0 to represent
    the absence of a contact (_Target_Type_None_).

Room_Handle
    A nonzero _Handle_ of type _Target_Type_Room_, or 0 to represent
    the absence of a room (_Target_Type_None_).

We could also consider stealing terminology from telepathy-logger and calling
it "entity type"... but Tpl's TplEntityType has a separate entry for "self",
which is represented as a Contact in Tp. I suppose there's nothing to stop us
from introducing Entity_Type_Self and documenting that the Self and Contact
"namespaces" overlap?

Another thing we could consider would be moving the Target_Type_None channels
to Target_Type_Server (Bug #70489).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.