For named chatrooms, the closest we can currently get is:

    { ...TargetHandleType: ROOM, ...ChannelType: ...Text }

but we want to exclude chatrooms that don't have a human-readable name (Room2.RoomName = "").

Proposal: add Room2.HasRoomName and have Polari match this:

    { ...TargetHandleType: ROOM, ...ChannelType: ...Text, ...HasRoomName: True }

For 1-1 messages, the filter syntax can't currently say anything about the protocol of a channel.

One solution for the protocol bit is Bug #30963 but I never really liked that proposal - I suspect it's rather more general than we actually need.

Another possible solution is: extend the MC filter syntax so some special token ("protocol"?) is special-cased to match against the Channel's Connection's protocol instead of the immutable properties. We can add further tokens, distinguished from D-Bus properties somehow (not containing a dot? starting with a character that isn't valid in an interface?), as and when we need them.

Another possibility would be to define a redundant Channel.Protocol property so that filters can use it.

For 1-1 messages related to a chatroom, again, we don't have an answer.

One way would be for Polari to pop up one additional Handler head per channel it handles, with a filter like this (assume we add suitable properties to the Channel):


    {
        ...ChannelType: ...Text,
        ...TargetHandleType: CONTACT,
        Hypothetical.Channel.I.RoomRelated1.RelatedToRoom: "telepathy@rooms.example.com",
     }

but there's a race condition there between "1-1 IM comes in from a contact" and "Mission Control inspects the Handler and finds out that it wants this".

Another way would be to have a boolean RelatedToRoom = True, and have Polari be the handler for such channels. The down side there is that it can't distinguish between "a room Polari is handling" and "a room someone else is handling for some reason".

Maybe there's another way but I can't think of it right now.

(In reply to comment #0)
> fmuellner would like Polari to be the Handler for:
> 
> * named chatrooms on IRC and XMPP

+1 for the HasRoomName solution, neat!

> * private messages from IRC contacts

I guess we can add a special ChannelClass key in the asv "protocol: $foo"

> * private messages mediated via XMPP chatrooms
>   (e.g. a 1-1 channel with telepathy@chatrooms.example.com/smcv)

Can MC know from which room channel "telepathy@chatrooms.example.com/smcv" comes from? If yes it can get that room channel's handler in priority to dispatch the 1-1 channel.

(In reply to comment #4)
> (In reply to comment #0)
> > * private messages mediated via XMPP chatrooms
> >   (e.g. a 1-1 channel with telepathy@chatrooms.example.com/smcv)
> 
> Can MC know from which room channel "telepathy@chatrooms.example.com/smcv"
> comes from? If yes it can get that room channel's handler in priority to
> dispatch the 1-1 channel.

If MC can't know that, maybe the hint can come from Gabble: add an immutable property on the Channel: "RelatedToRoom: $room_object_path". Then MC can use that property to lookup who is currently handling $room_object_path and pick that handler first. I think it is a good general rule that channels related to another channel gets the same handler.

can even be totally general: the CM can decide that any channel is ReletatedTo any other channel. And MC use that hint to pick the handler in the case more than one handler can equally handle a channel.

(In reply to comment #2)
> For 1-1 messages, the filter syntax can't currently say anything about the
> protocol of a channel.

The implementation in MC for this turns out to be pretty easy.

Another way this could work would be for Polari to have an Observer "head" for all incoming 1-1 Text channels (under a secondary name not listed in a .client file, so that it's only active while Polari is running), and non-interactively approve those that turn out to be IRC by using HandleWith('...Polari') or Claim(). If it does that, it should follow the usual rule of not acknowledging messages until it is "officially" the Handler.

That would mean that Text Approvers never see those channels - does that match what we want in practice?

That would also interact poorly with a hypothetical second client that was doing the same thing (does anything?) - if you're running two concurrent clients, both of which try to claim all incoming channels without user interaction, then Mission Control will say "yes" to whichever one gets its request in first, and it'll be non-deterministic which one ends up with the channel.

On the other hand, if you consider it to be OK for new messages to show up in more than one place, it could be a simultaneous Observer/Handler, display the messages, ack the messages if and only if it's currently the Handler, and otherwise not care too much about whether it wins or loses the race?

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #0)
> > > * private messages mediated via XMPP chatrooms
> > >   (e.g. a 1-1 channel with telepathy@chatrooms.example.com/smcv)
> > 
> > Can MC know from which room channel "telepathy@chatrooms.example.com/smcv"
> > comes from?

Not without help from the CM.

> If MC can't know that, maybe the hint can come from Gabble: add an immutable
> property on the Channel: "RelatedToRoom: $room_object_path". Then MC can use
> that property to lookup who is currently handling $room_object_path and pick
> that handler first. I think it is a good general rule that channels related
> to another channel gets the same handler.

Polari would need some way to say: I am able to deal with 1-1 text channels, but please don't actually give me those channels unless they are related to one I'm already handling.

(In reply to comment #8)
> Polari would need some way to say: I am able to deal with 1-1 text channels,
> but please don't actually give me those channels unless they are related to
> one I'm already handling.

That's quite similar to Bug #31325.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/143.