[Bug 20774] ConnectionManager: Protocol objects

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=20774





--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-03-02 11:07:12 PST ---
Depending on the constraints we want to enforce, TpBaseConnectionManager might
be able to synthesize Protocol objects for existing connection managers without
the CM being changed. These Protocol objects wouldn't be particularly useful:
Parameters would be populated, but Guaranteed*, Possible* would be empty, and 
IdentifyAccount and NormalizeContact would both raise NotImplemented.

There are basically two ways we can go:

* Declare that these Protocol objects are legal, and clients have to cope with
all the other properties being unpopulated. TpBaseConnectionManager can
synthesize and export Protocol objects.

* Declare that these Protocol objects are not allowed, so
TpBaseConnectionManager can't export them until CMs fill in the rest of the
required information.

I think I prefer the latter, since TpConnectionManager needs a fallback path to
ListProtocols/GetParameters anyway (to cope with older telepathy-python CMs).

> [Bikeshedding: perhaps the following should be on a Protocol.Avatars interface]

I think they should.

> [Bikeshedding: perhaps the following should be on a Protocol.SimplePresence
> interface]

I think they should.

(In reply to comment #8)
> I would also like:
> 
>   as: PossibleSidecars
>   as: GuaranteedSidecars

Those should probably be another interface too.

(In reply to comment #4)
> A serialization in the .manager file also needs to be defined. Everything's
> probably quite easy, except for the requestable channel classes which are Hard.

If we forbid RCCs with non-serializable fixed properties, it becomes
considerably easier - we can adapt the serialization from .client files.

(In reply to comment #6)
> * preferred/common vCard field for this protocol (e.g. x-jabber for XMPP)

readable property VCardField: s

    The name of the most common vCard field used for this protocol's contact
    identifiers, normalized to lower case, or the empty string if there is
    no such field.

    | For instance, in XMPP this would be "x-jabber", and in telephony it
    | would be "tel".

> * human-readable protocol name, defined to be in the C locale (UIs can gettext
> it with their own locale if necessary)

readable property DisplayName: s

    The name of the protocol in a form suitable for display to users,
    such as "AIM" or "Yahoo!", or the empty string if none is available.

    This is effectively in the C locale (international English);
    user interfaces requiring a localized protocol name SHOULD look
    one up in their own message catalog based on either the Telepathy
    #Protocol name or this property, but SHOULD use this English version
    as a fallback if no translated version can be found.

    | Many protocols are named after a company or product which isn't
    | translated in non-English locales. This also provides a fallback
    | display name, for UIs with no prior knowledge of a particular protocol.

    If this property's value is empty, clients MAY fall back to using
    the Telepathy #Protocol name, possibly with its capitalization adjusted.

> * default protocol icon name, overridable via presets

readable property Icon: s

    The name of an icon in the system's icon theme, such as "im-msn", or
    the empty string.

    | This can be used as a default if the @Icon property is not set on an
    | #Account, or used by the #AccountManager to choose a default icon
    | if none is set during account creation.

    If this property's value is empty, clients MAY fall back to generating
    a name based on the #Protocol name.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.