[Telepathy] Group interface usage?

[Tobias Hunger]

On Thursday 19 July 2007, Simon McVittie wrote:
> (The group interface isn't an object but an interface - it's not
> "created along with the channel", it *is* (a view of) the channel.)

You are right here of course.

> When NewChannel is signalled, it's CM-defined what members exist in the
> channel. For incoming calls, I'd say it's likely but not guaranteed that
> the remote user will be in Members and the local user will be in
> LocalPending.
>
> We should probably either tighten up the spec to make that guarantee, or
> explicitly say that it's not guaranteed and clients might need to delay
> dealing with the channel until they find out who's calling.

The Spec (0.15.4) says this in the section on the Group interface:
"The lists are empty when the channel is created, and the MembersChanged 
signal should be emitted when information is retrieved from the server, or 
changes occur."

As I understand this the spec is explicitly saying that what you (and I) 
consider to be likely is not the case.

<snip>

> If you're relying on what's the case at the exact moment NewChannel is
> emitted, bear in mind that by the time you've made a method call to find
> the members, they may well have changed - you're leaving yourself open to
> race conditions if you try to rely on exact timings.

You are right again. But you have to examine the members at some point. It 
would be good to know that the Group interface was properly set up by the 
time a NewChannel signal is emitted. Otherwise there is no way of knowing 
when the initial setup is done. Is it after the first MembersChanged signal 
or only later?

IMHO it would be much better to be done with all the setup by the time the 
NewChannel signal is emitted.

> If you're just deciding whether the channel is an incoming or outgoing
> call, you should be able to tell by where the local user is in the group
> interface.

Yes, but only after the Group Interface was set up. If the group interface is 
empty when the NewChannel is emitted, then I am stuck.

> If you're deciding whether you should launch a UI to handle the channel
> or rely on someone else already having taken responsibility, that's what
> the suppress_handler flag is for.

I know.

> If it's TRUE you should assume that 
> some other process is already handling the channel (most likely, the
> process that requested it), if it's FALSE you should launch a suitable
> UI with which to handle it.

The problem is not when to look for some application to handle a channel, but 
which application to choose. Decibel uses the target/origin of a channel as 
one criteria to decide this. This is useful to eg redirect text messages, 
calls and everything else from known spammers to /dev/null.

> If you're deciding what to do based on the identity of the remote user,
> for outgoing calls you'll have to wait til the local UI decides who it
> wanted to call.

True. I tried using crystal balls, but they are so unreliable when put close 
to a multi-GHz CPU;-)

> Channels don't have status, connections have status. The closest
> equivalents of connection status on a channel are the group interface's
> local-pending/remote-pending/members sets, which is why we use them for
> streamed media channels.

Of course all the streams have a state as well:-)

Best Regards, and thanks for your explanations!

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20070720/8dd5bd37/attachment.pgp