(In reply to comment #0)
> Is there any reason that Client objects must be immutable?

Service-activatable Clients with a .client file have to be immutable in order to avoid the .client file being full of lies.

Non-activatable Clients are immutable to avoid adding more complexity to an already-subtle spec; it took quite a long time to get ChannelDispatcher designed and implemented in MC 5, and we still haven't quite finished getting MC 5 to implement the spec *correctly* :-)

> Rob says, it would be nice to have a backwards compatible way of notifying the
> CD of changes to a client's filters.

That way is to have multiple Client heads. Empathy implements two clients, Empathy (service-activatable for basic functionality - Text at the moment, I think?), and Empathy.MoreThanMeetsTheEye (bonus functionality like file transfers and VoIP).

Adding a filter: add a Client head (then optionally remove any old Client head that is a subset of the new one)

Removing a filter: add a Client head with the appropriate subset of filters, then remove the old Client head that had the superset

Based on implementation experience, we could consider having change-notification in Telepathy 1.0, but my instinct is to say that that would add more complexity than it was worth. The ChannelDispatcher has to deal with Clients appearing and disappearing *anyway*, so if we make the filters immutable and use multi-headed Clients to implement filter changes, we get that functionality without any extra code.

-- 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/54.