[Bug 24939] Interface for upgrading chats/calls to multi-user

[bugzilla-daemon at freedesktop.org]

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





--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-11-13 10:55:46 PST ---
One subtlety of having a "replace this channel" API is that we should
avoid the appearance of altering the immutable properties of a channel:
the replacement channel should appear at a different object path. Here's a 
solution that I think should be rejected, because it does not have that
property:

Having the replacement appear at the same object path is *technically*
allowed by telepathy-spec, and it's tempting to use this as a solution.
It could even be the same C object inside the connection manager, by
using the same trick that our CMs do to "respawn" closed Text channels
with unacknowledged messages:

* [begin critical section in which the main loop must not be re-entered]
* emit Closed (conceptually, this removes the old Channel)
* adjust the properties that would normally be immutable
* emit NewChannel and NewChannels (conceptually, this replaces the old
  Channel with a new one that "coincidentally" has the same object path)
* [end critical section; you may re-enter the main loop now]

This would look a lot like the proposed solution, except that C1/C3 is closed a
moment before C2/C4 is created at the same object path. Conceptually,
C2/C4 is still a new channel, and the ChannelDispatcher will behave as such, so
the only possible simplification is within the connection manager's code.

We'd discourage doing this. It's easy to get wrong, and if you
get the subtle details slightly wrong in either the client or the CM,
it looks as though you're violating some quite fundamental Telepathy
API guarantees (that the immutable properties are immutable).

If we recycle object paths, there's also an unavoidable possibility that
you'll try to call a method on the old channel, and instead have the
method-call message delivered to the new one. This is bad if the method
call is Close(), and very bad if the method call is Send() (you might
accidentally send the message to people you didn't think would see it -
the anti-use-case from Comment #1).


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