Brainstorming: Breaking Telepathy Client Model and Text handling
Case where we have two handlers requires a mess of support for redelegating channels
Why do text channels even need handlers? Most of the spec directions on who acknowledges messages predates the PendingMessageRemoved signal and assumes clients will ack messages when they're rendered, rather than when the user has seen them (which is the assumption used by Empathy, gnome-shell, Anerley, etc.).
If all text channels were Observers (or just "clients"), we wouldn't need any complex redelegation infrastructure. All clients are just views on the text channel.
Very scrappy notes
Since last week, both Empathy and the Shell are handlers for Text channels. We have API to delegate a channel from one handler to another, so the Shell can hand over a channel it's handling to Empathy. But when the Shell is handling a channel, if you double-click the contact in the contact list, it just presents the Shell thing.
So Guillaume started implementing API to make the Shell, when told to re-present the channel, pass it over to the PreferredHandler.
Currently, applications have to listen both to the logger, and to MessageReceived on the text channel. This pretty much guarantees that they'll get it wrong. It would be easier if text UIs were just views on the logger.
Relatedly: there's currently a possibility to miss messages because when you get a new channel, the logger has to go back and ask the CM what the messages were. If you lose your network connection in the gap, then the connection goes away and the channel with it, and now you've lost perfectly good messages. If the logger could be notified of all new connections and bind to all MessageReceived signals, then this race would not exist. Ditto calls: if the logger were watching all NewChannels signals, then you wouldn't have situations where missed call information could be lost.
One handler per channel model works well for file transfers and calls and … everything except text.
Logger could be better and more reliable if it were solely responsible for handling text channels. • only approval case for text: group chats • at least two kinds of acknowledgement: ∘ i've written this to persistent storage ∘ i've rendered some pixels ∘ the user has read the pixels • if we decouple storage-acking and shown-to-the-user acking, it's much more useful for CMs and for the UI
If we make the logger be the point of focus for text chats, what happens when you open an empathy conversation window: does it open a channel? does it just open a view on the logger?
1-1 text channels are different to other channel types in that the channel itself isn't the interesting event, it's the events signalled by the channel. whereas for MUCs the existence or not of the channel is interesting, and for calls, etc. the channel is the event.
An aside about whether we want to support moving channels of other types between clients? eg. moving calls from the shell to a separate call window? a clarification that we can have an “answer”/“reject” dialog shown by the shell, but have the call itself still be shown in a separate empathy window.
We can add connection-level observers and make the logger bind directly to MessageReceived to avoid losing messages, without making the logger be the sole handler for text channels. Figuring out the text channel focus issue is distinct.
Single-handler thing could solve the Shell notification for foregrounded window thing? Maybe Empathy could delegate channels back to the Shell when they're not in the foreground? (Bad idea, says everyone.)
If we make the Logger the Handler, we lose PresentChannel() working. We also lose a way to say we don't have a handler so we shouldn't accept text messages: but if you're using Telepathy but don't have a text handler, maybe you lose? On some protocols you can be call capable but not text capable.
If we make MessageReceived always get emitted after NewChannels, we will probably discover that the code for getting the pending queue from text channels has been racy all along? But we believe both telepathy-qt4 and telepathy-glib are correct here.
We could make channel handlerdom be more like D-Bus name ownership, where you can have handlerness taken away from you? This seems unwise.
The channel handlers can be made views on loggers without making the logger the handler, too. So making it actually be the handler doesn't buy us much: we can still have handlers be handlers to bounce channels around with MC's assistance, and they can still bounce stuff around.
We do need to have the logger acking messages and have a separate concept of unread/read in the logger: because this allows us to track messages being read or not across sessions, and also removes a race where the logger crashing can mean we lose messages.
So back onto the client model: the channels effectively go through specific states, but you have to register for each state if you care. Rob suggests turning this inside out, so that channel dispatches actually have three states, and there's only one kind of client. (Simon points out that “Shell is not simultaneously a O A H and that's weird”, it's really “Shell is interested in all three states”.) This makes how you want to act implicit, and the states explicit; as opposed to the status quo, which is vice versa.
Client API makes it “very easy to introduce more flavours of client into the middle”. We've added quite a few weird special cases to the MC dispatch pipeline, and the D-Bus model copes with it fine. So the implication is: the *real* state diagram is incredibly complicated, and the D-Bus API gives you quite a nice smaller view on it. Making the real state diagram be visible to Telepathy-based applications may not actually make applications simpler.
If we made Mission Control be the logger, then the titular handler doesn't have to tell the logger to ack messages now because someone is handling it because the logger already knows because it is the channel dispatcher. And also this would mean that we don't need connection observers because it is MC (although we still want connection observers for other applications).
We can solve some of the O/A/H convolution by making the C/C++ API easier.