[Bug 20774] ConnectionManager: Protocol objects

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|review-                     |

--- Comment #13 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-13 10:07:08 PDT ---
Updated branch:

smcv/protocols in git
http://people.freedesktop.org/~smcv/telepathy-spec-protocols/spec/
http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/protocols

It has been rebased to get rid of Sidecars: the last commit that has been
reviewed is "fd.o #17836: Protocol: add VCardField, DisplayName and Icon".

(In reply to comment #12)
> IdentifyAccount:
> 
> • This makes it possible for MC's account path to be sensible, and be
>   the same if you delete and re-create account so that your old logs
>   match up.
> • Also solves the problem where you can create two accounts for the
>   same JID and then can't actually connect them both at once, as Siraj
>   mentioned on #telepathy today.
> • We could add an "IRC Network" parameter which Idle ignores but uses
>   to generate responses to this? This would mean that if you switch
>   between two servers on the OFTC network, the account path could
>   still be wjt at OFTC or something.

No action taken.

> NormalizeContact:
> • Needs explanation of why it's best-effort only

Done

> • Why might it raise NotImplemented? Salut.

Done

> Guaranteed vs. Possible {Interfaces,ChannelClasses}:
> • Why would you ever care about anything other than the union?

Flattened into ConnectionInterfaces and RequestableChannelClasses.

> • Should we distinguish between channel classes that every contact will
>   have, channel classes that some contacts may have, and channel
>   classes that the whole connection might not even have when you sign
>   in?
>   · Again, what would the UI do differently in each case?

Tentative resolution: no, we shouldn't.

> • Possible route: just have one list for each, we can reintroduce
>   Guaranteed later if needed.

Done.

> Agreed that presets such as settings for well-known SIP providers,
> Google Talk, Ovi etc. don't live here; they should live outside the CM,
> so that you can install extra files to describe (e.g.) your company's
> SIP or XMPP service.

No action taken.

> VCardField:
>   · as a first step, if you have a vCard and it's got an x-jabber field
>     and you want to know how you can contact this person, you can just
>     go through your protocols and find them.
>   · this is stolen directly from MC's profiles as used on Maemo 5, and
>     is valuable there.

Documented.

>   · this is not for getting a contact out of a protocol and turning it
>     into a vCard field, because a protocol might support several.
>     Example: SIP supports tel and sip. this use case is further work.

Documented.

>   · nitpick, explain what "telephony" means, exactly: it's Ye Olde POTS,
>     not IP Telephony.

Done (I called it "the PSTN", consistent with "tel" in the Protocol
tp:simple-type).

> DisplayName:
>   · This is a really overloaded name; can we call it EnglishName?

Done.

> Icon:
>   · "system's icon theme" is a bit of a cop-out. can we say xdg icon
>     spec names?

If
<http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html>
is still the latest, then no, we can't - they're not there. :-(

No action taken. I copied the wording from Account.Icon.

> Protocol.Interface.Presence:
>   · Maybe guaranteed vs. possible makes sense here?
>   · Counter-argument: what's the UI meant to do if you say "you might
>     be able to be invisible? i don't really know?"
>   · Will reckons we should just make Gabble support invisible
>     everywhere which removes the one case where possible ≠ guaranteed

Flattened into Statuses.

One possible change here is to represent the Connection_Presence_Type by a
string rather than an integer (the suffix of the enum value might be a good
choice - Available, Extended_Away, Busy etc.).

> Sidecars we'll ignore for now; the rest seems fine.

I rebased the branch to re-order all the sidecars stuff to the end.
smcv/protocols now contains everything except sidecars, and
smcv/protocol-sidecars contains the sidecar interface.

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