[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 #7 from Naveen <ernaveenverma at gmail.com>  2009-11-14 06:49:12 PST ---
(In reply to comment #4)
> 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).
> 

This is pretty much same what is happening in skype connection manager at the
moment which client interface doesn't like.


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