[Bug 20774] ConnectionManager: Protocol objects

[bugzilla-daemon at freedesktop.org]

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


Will Thompson <will.thompson at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|specmeet?                   |




--- Comment #12 from Will Thompson <will.thompson at collabora.co.uk>  2010-03-30 11:28:22 PST ---
Spec meeting notes!

Implementation details:

• the tp-glib implementation involves subclassing TpBaseProtocol. it
  supports CMs like haze which discover their own protocols at
  run-time, as well as CMs that have one or two staticly-determined
  protocols.

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.

NormalizeContact:

• Needs explanation of why it's best-effort only, with reference to XMPP
  where foo at conference.bar/bong.hits would be normalized to
  foo at conference.bar by this method even though that's wrong.
• Why might it raise NotImplemented? Salut.

Guaranteed vs. Possible {Interfaces,ChannelClasses}:
• Why would you ever care about anything other than the union?
• 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?
• Possible route: just have one list for each, we can reintroduce
  Guaranteed later if needed.

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.

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.
  · 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.
  · nitpick, explain what "telephony" means, exactly: it's Ye Olde POTS,
    not IP Telephony.

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

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

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

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


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