Re: 3.12 feature: polari

[Simon McVittie <simon mcvittie collabora co uk>]

On 11/10/13 10:25, Ross Burton wrote:
> On 11 October 2013 10:21, David Woodhouse <dwmw2 infradead org
> <mailto:dwmw2 infradead org>> wrote:
>
>     > Why stop at IRC? Given that the engine is Telepathy, we could use it
>     > for named rooms on any protocol, like XMPP MUCs for instance. Is there
>     > some limitation somewhere that makes it only suitable for IRC?
>
>     So this would be a replacement for Empathy?
>
> Or be a better alternative to Empathy for rooms, leaving Empathy (or
> eventually, Contacts + Shell, I guess) for IM.

In the past, various people have talked about cutting the "named
chatroom" UI out of Empathy and replacing it with something based on the
xchat-gnome UI.

This seems broadly similar - it's new code rather than xchat-gnome, but
the principle of "have a UI designed for a particular purpose" seems
similar.

For completeness, I should point out that because IM protocols are
annoyingly varied, Telepathy has four types of Text channel, which are
sufficiently different at the protocol level that we distinguish between
them on D-Bus. I list them here in the hope that the developers of GNOME
Telepathy UIs can make an informed decision about their UIs' scope,
rather than getting a particular set of channels "by mistake" as a
result of implementation details :-)

- one-to-one messages[1]: PRIVMSG on IRC, IMs on XMPP, SMSs in
  telepathy-ring, etc. Currently handled by Shell and Empathy,
  could be handled by Chat in future

- nameless ad-hoc chatrooms[2]: what you get when you add a a contact
  to a one-to-one conversation, in protocols that let you do that, like
  MSNP and Skype). I don't think any current Telepathy CMs do this,
  but telepathy-butterfly used to do this for MSNP, and I think the
  proprietary Telepathy CM on the N900/N9 did this for Skype.
  Is Chat going to be the handler for these? I would personally give
  these the same UI as one-to-one channels, if I was implementing
  a UI (I'm not).

- ad-hoc chatrooms with a meaningless name (a UUID or something)[3]:
  this is what you get when you add a contact to a one-to-one
  conversation on Google Talk. It should be presented in UIs in the
  same way as a nameless ad-hoc chatroom, but is different at the
  protocol level (loggers can use the name to tie together
  conversations, for instance). Is Chat going to be the handler for
  these? Again, I would personally group them together with one-to-one
  channels.

- chatrooms with a human-meaningful name (e.g. #telepathy on IRC,
  jdev conference jabber org on XMPP)[4]. If I understand correctly,
  this is what Polari is meant for? I think these do make sense
  to have a less message-oriented and more room-oriented UI
  (a "room/location/conference" rather than "chat" metaphor).

If you want to match channels by protocol (e.g. an IRC-only UI), either
we'll have to introduce new handler matching API, or GNOME Shell will
have to learn to discriminate between multiple UIs that
telepathy-misison-control considers "equally good". Either is completely
do-able, but we do need to understand the use-cases before we design.

Regards,
    S

[1] Telepathy channel filter: {
    ...ChannelType = ...Text, TargetHandleType = CONTACT
    }
[2] Telepathy channel filter: {
    ...ChannelType = ...Text, TargetHandleType = NONE
    }
[3] Telepathy channel filter: {
    ...ChannelType = ...Text, TargetHandleType = ROOM,
    ...Room2.RoomName = ""
    }
[4] Telepathy channel filter: {
    ...ChannelType = ...Text, TargetHandleType = ROOM
    }
    (and because Mission Control has "closest match first"
    semantics, filter [3] will take precedence for nameless
    rooms)